home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 9 / QRZ Ham Radio Callsign Database - Volume 9.iso / pc / files / t_docs / ka9qnos.nr < prev    next >
Text File  |  1996-06-24  |  108KB  |  2,660 lines

  1. .ds RF March 3, 1991
  2. .ds LF updated by Bill Simpson
  3. .TL
  4. NET User Reference Manual (NOS Version)
  5. .AU
  6. Phil Karn, KA9Q
  7. .nr LL 6.5i
  8. .NH 1
  9. The NET.EXE Program
  10. .LP
  11. The MS-DOS executable file \fBnet.exe\fP provides Internet (TCP/IP),
  12. NET/ROM and AX.25
  13. facilities.  Because it has an internal multitasking operating system,
  14. \fBnet.exe\fP can act simultaneously as a client, a server and a packet switch
  15. for all three sets of protocols. That is, while a local user accesses remote
  16. services, the system can also provide those same services to remote users
  17. while also switching IP, NET/ROM and AX.25 packets and frames between other
  18. client and server nodes.
  19. .LP
  20. The keyboard and display is used by the local operator to control both host
  21. and gateway level functions, for which a number of commands are provided.
  22. .NH 2
  23. Installation
  24. .LP
  25. \fBNet.exe\fP uses the following directory structure:
  26. .DS
  27. /net
  28. /net/spool
  29. /net/spool/help
  30. /net/spool/mail
  31. /net/spool/mqueue
  32. /net/spool/rqueue
  33. /net/spool/news
  34. .DE
  35. .LP
  36. The "/net" directory is not strictly necessary, and defaults to the root
  37. of the current drive.  Any name may be chosen using the \fB-d\fP command-line
  38. option (described below).
  39. The \fBalias, autoexec.net, dialer, domain.txt\fP and \fBftpusers\fP
  40. configuration files are located here.
  41. .LP
  42. The "/spool" directory and its sub-directories are used by the bbs,
  43. SMTP and NNTP services.
  44. The \fBareas, forward.bbs, history, mail.log, rewrite\fP and \fBsignatur\fP
  45. configuration files are located here.
  46. .LP
  47. The \fBalias, forward.bbs\fP and \fBrewrite\fP files are described in the
  48. document "maildoc", which should be found at the same location as this file.
  49. .NH 2
  50. net [-b] [-s <sockets>] [-d <directory>] [<startup file>]
  51. .NH 3
  52. -b
  53. .LP
  54. The \fB-b\fP option specifies the use of BIOS for console output;
  55. the default is to write directly to the video display buffer. Use
  56. this option if you are running under a windowing package and have
  57. trouble with output "bleeding through" on top of other windows.
  58. .NH 3
  59. -s
  60. .LP
  61. The \fB-s\fP option specifies the size of the
  62. \fIsocket\fP array to be allocated within \fBnet.exe\fP. This limits the number
  63. of network connections that may exist simultaneously.
  64. The default is 40.
  65. .NH 3
  66. -d
  67. .LP
  68. The \fB-d\fP option allows the user to specify a directory for the
  69. configuration and spool files; it defaults to the root directory of the system.
  70. .NH 3
  71. Startup file
  72. .LP
  73. After all command-line options, the name of a startup file may be specified.
  74. If no startup file is specified, \fBnet.exe\fP attempts to open a file named
  75. \fBautoexec.net\fP in the configuration directory of the current drive.
  76. If the file exists,
  77. it is read and executed as though its contents were typed on the
  78. console as commands.
  79. (See the \fBCommands\fP chapter.)
  80. This feature is useful for attaching communication
  81. interfaces, configuring network addresses, and starting the various services.
  82. .bp
  83. .NH 1
  84. Console modes
  85. .LP
  86. The console may be in one of two modes: \fIcommand mode\fP and
  87. \fIconverse mode\fP.
  88. In \fIcommand mode\fP, the prompt \fBnet>\fP is displayed and any of the
  89. commands described in the \fBCommands\fP chapter may be entered.
  90. In \fIconverse mode\fP,
  91. keyboard input is processed according to the \fIcurrent session\fP.
  92. .LP
  93. Sessions come in many types, including \fITelnet, FTP, AX25,
  94. NETROM, Ping, More, Hopcheck\fP and \fITip\fP.
  95. In a Telnet, AX25, NETROM, or Tip session, keyboard input is sent to the
  96. remote system and any output from the remote system is displayed on the
  97. console.  In a FTP session, keyboard input is first examined to see if
  98. it is a known local command; if so it is executed locally.  If not, it
  99. is "passed through" to the remote FTP server.
  100. (See the \fBFTP Subcommands\fP chapter).
  101. In a Ping session the user may test the path to a
  102. remote site, and in a More session, the user may examine a local
  103. file. A Hopcheck session is used to trace the path taken by packets
  104. to reach a specified destination.
  105. .LP
  106. The keyboard also has \fIcooked\fP and \fIraw\fP states.
  107. In \fIcooked\fP state, input
  108. is line-at-a-time; the user may use the line editing characters ^U, ^R
  109. and backspace to erase the line, redisplay the line and erase the last
  110. character, respectively.  Hitting either return or line feed passes the
  111. complete line up to the application.
  112. In \fIraw\fP state, each character is
  113. immediately passed to the application as it is typed.
  114. .LP
  115. The keyboard is always in \fIcooked\fP state in command mode.
  116. It is also \fIcooked\fP in converse mode on an AX25, FTP or NET/ROM session.
  117. In a Telnet session it depends on
  118. whether the remote end has issued (and the local end has accepted) the
  119. Telnet WILL ECHO option (see the \fBecho\fP command).
  120. .LP
  121. On the IBM-PC, the user may escape back to \fIcommand mode\fP
  122. by hitting the F10 key.
  123. On other systems, the user must enter the \fIescape\fP character,
  124. which is by default control-] (hex 1d, ASCII GS).
  125. (Note that this is distinct from the ASCII character of the same name).
  126. The \fIescape\fP character can be changed (see the \fBescape\fP command).
  127. .LP
  128. In the IBM PC version, each session (including the command "session")
  129. has its own screen.
  130. When a new session is created,
  131. the command display is saved in memory and the screen is cleared.
  132. When the command escape key (usually F10) is hit,
  133. the current session screen is saved and the command screen is restored.
  134. When a session is resumed,
  135. its screen is restored exactly as it appeared when it was last current.
  136. .bp
  137. .NH 1
  138. Commands
  139. .LP
  140. This chapter describes the commands recognized in command mode,
  141. or within a startup file such as \fBautoexec.net\fP.
  142. These are given in the following notation:
  143. .DS
  144. command
  145. command literal_parameter
  146. command subcommand <parameter>
  147. command [<optional_parameter>]
  148. command a | b
  149. .DE
  150. .LP
  151. Many commands take subcommands or parameters, which may be optional or
  152. required. In general, if a required subcommand or parameter is omitted,
  153. an error message will summarize the available subcommands or required
  154. parameters.  (Giving a '?' in place of the subcommand will also generate the
  155. message.  This is useful when the command word alone is a valid command.) If
  156. a command takes an optional value parameter, issuing the command without the
  157. parameter generally displays the current value of the variable. (Exceptions
  158. to this rule are noted in the individual command descriptions.)
  159. .LP
  160. Two or more parameters separated by vertical bar(s) denote a choice between
  161. the specified values.  Optional parameters are shown enclosed in [brackets],
  162. and a parameter enclosed in <angle brackets> should be replaced with an
  163. actual value or string.  For example, the notation \fB<hostid>\fP denotes an
  164. actual host or gateway, which may be specified in one of two ways:
  165. as a numeric IP address in dotted decimal notation (eg. 44.0.0.1), or
  166. as a symbolic name listed in the file \fBdomain.txt\fP.
  167. .LP
  168. All commands and many subcommands may be abbreviated. You only need
  169. type enough of a command's name to distinguish it from others that
  170. begin with the same series of letters. Parameters, however, must be
  171. typed in full.
  172. .LP
  173. Certain FTP subcommands (eg. \fBput, get, dir\fP, etc) are recognized
  174. only in converse mode with the appropriate FTP session; they are not
  175. recognized in command mode.
  176. (See the \fBFTP Subcommands\fP chapter.)
  177. .NH 2
  178. <CR>
  179. .LP
  180. Entering a carriage return (empty line) while in command mode puts you in
  181. converse mode with the current session. If there is no current session,
  182. \fBnet.exe\fP remains in command mode.
  183. .NH 2
  184. !
  185. .LP
  186. An alias for the \fBshell\fP command.
  187. .NH 2
  188. #
  189. .LP
  190. Commands starting with the hash mark (#) are ignored. This is mainly useful
  191. for comments in the \fBautoexec.net\fP file.
  192. .NH 2
  193. abort [<session #>]
  194. .LP
  195. Abort a FTP \fBget, put\fP or \fBdir\fP operation in progress. If issued without
  196. an argument, the current session is aborted. (This command works only
  197. on FTP sessions.) When receiving a file, \fBabort\fP
  198. simply resets the data connection; the next incoming data packet will generate
  199. a TCP RST (reset) response to clear the remote server.  When
  200. sending a file, \fBabort\fP sends a premature end-of-file. Note that in both
  201. cases \fBabort\fP will leave a partial copy of the file on the destination
  202. machine, which must be removed manually if it is unwanted.
  203. .NH 2
  204. arp
  205. .LP
  206. Display the Address Resolution Protocol table that maps IP addresses
  207. to their subnet (link) addresses on subnetworks capable of broadcasting.
  208. For each IP address entry the subnet type (eg. Ethernet, AX.25), subnet
  209. address and time to expiration is shown. If the link address is currently
  210. unknown, the number of IP datagrams awaiting resolution is also shown.
  211. .NH 3
  212. arp add <hostid> ethernet | ax25 <ethernet address> | <ax25_address>
  213. .LP
  214. Add a permanent entry to the table. It will not time out
  215. as will an automatically-created entry, but must be removed with the
  216. \fBarp drop\fP command.
  217. .NH 3
  218. arp publish <hostid> ethernet | ax25 <ethernet address> | <ax25_address>
  219. .LP
  220. This command is similar to the \fBarp add\fP command, but
  221. system will also respond to any ARP request it sees on the network that seeks
  222. the specified address.  (Use this feature with great care.)
  223. .NH 3
  224. arp drop <hostid> ax25 | ethernet
  225. .LP
  226. Remove the specified entry from the ARP table.
  227. .NH 3
  228. arp flush
  229. .LP
  230. Drop all automatically-created entries in the ARP table; permanent
  231. entries are not affected.
  232. .NH 2
  233. asystat
  234. .LP
  235. Display statistics on attached asynchronous communications interfaces
  236. (8250 or 16550A), if any. The display for each port consists of three
  237. lines. The first line gives the port label and the configuration flags;
  238. these indicate whether the port is a 16550A chip, the \fItrigger character\fP
  239. if any,
  240. whether CTS flow control is enabled,
  241. whether RLSD (carrier detect) line control is enabled,
  242. and the speed in bits per second.
  243. (Receiving the \fItrigger character\fP causes the driver
  244. to signal upper layer software that data is ready;
  245. it is automatically set to the appropriate frame end
  246. character for SLIP, PPP and NRS lines.)
  247. .LP
  248. The second line of the status display shows receiver (RX) event counts: the
  249. total number of receive interrupts, received characters, receiver overruns
  250. (lost characters) and the receiver \fIhigh water mark\fP.
  251. The high water mark is
  252. the maximum number of characters ever read from the device during a single
  253. interrupt. This is useful for monitoring system interrupt latency margins as
  254. it shows how close the port hardware has come to overflowing due to the
  255. inability of the CPU to respond to a receiver interrupt in time. 8250 chips
  256. have no FIFO, so the high water mark cannot go higher than 2 before overruns
  257. occur. The 16550A chip, however, has a 16-byte receive FIFO which the
  258. software programs to interrupt the CPU when the FIFO is one-quarter full.
  259. The high water mark should typically be 4 or 5 when a 16550A is used; higher
  260. values indicate that the CPU has at least once been slow to respond
  261. to a receiver interrupt.
  262. .LP
  263. When the 16550A is used, a count of FIFO timeouts is also displayed on the
  264. RX status line. These are generated automatically by the 16550A when three
  265. character intervals go by with more than 0 but less than 4 characters in the
  266. FIFO. Since the characters that make up a SLIP or NRS frame are normally
  267. sent at full line speed,
  268. this count will usually be a lower bound on the number of frames received
  269. on the port, as only the last fragment of a frame generally results
  270. in a timeout (and then only when the frame is not a multiple of 4 bytes
  271. long.)
  272. .LP
  273. Finally, the software fifo overruns and high water mark are displayed.
  274. These indicate whether the <bufsize> parameter on the attach command
  275. needs to be adjusted (see the \fBAttach Commands\fP chapter).
  276. .LP
  277. The third line shows transmit (TX) statistics,
  278. including a total count of transmit interrupts, transmitted characters,
  279. the length of the transmit queue in bytes,
  280. the number of status interrupts,
  281. and the number of THRE timeouts.
  282. The status interrupt count will be zero
  283. unless CTS flow control or RLSD line control has been enabled.
  284. The THRE timeout is a stopgap measure to catch lost transmit interrupts,
  285. which seem to happen when there is a lot of activity
  286. (ideally, this will be zero).
  287. .NH 2
  288. attach <hw type> ...
  289. .LP
  290. Configure and attach a hardware interface to the system.
  291. Detailed instructions for each driver are in the \fBAttach Commands\fP chapter.
  292. An easy way to obtain a summary of the parameters required for a given device
  293. is to issue a partial attach command (eg. \fBattach packet\fP).
  294. This produces a usage message giving the complete command format.
  295. .NH 2
  296. ax25 ...
  297. .LP
  298. These commands are used for AX25 interfaces.
  299. .NH 3
  300. ax25 blimit [<count>]
  301. .LP
  302. Display or set the AX25 retransmission backoff limit. Normally each
  303. successive AX25 retransmission is delayed by twice the value of the
  304. previous interval; this is called \fIbinary exponential backoff\fP.
  305. When the backoff reaches the blimit setting it is held at that value,
  306. which defaults to 30.
  307. To prevent the possibility of "congestive collapse" on a loaded channel,
  308. blimit should be set at least as high as the number of stations sharing
  309. the channel.
  310. Note that this is applicable only on actual AX25 connections; UI frames
  311. will never be retransmitted by the AX25 layer.
  312. .NH 3
  313. ax25 digipeat [on | off]
  314. .LP
  315. Display or set the digipeater enable flag.
  316. .NH 3
  317. ax25 flush
  318. .LP
  319. Clear the AX.25 "heard" list (see \fBax25 heard\fP).
  320. .NH 3
  321. ax25 heard
  322. .LP
  323. Display the AX.25 "heard" list. For each interface that is configured to
  324. use AX.25, a list of all callsigns heard through that interface is
  325. shown, along with a count of the number of packets heard from each station
  326. and the interval, in hr:min:sec format, since each station was last heard.
  327. The local station always appears first in the listing; the packet count
  328. actually reflects the number of packets transmitted. This entry is always
  329. present even if no packets have been sent.
  330. .NH 3
  331. ax25 irtt [<milliseconds>]
  332. .LP
  333. Display or set the initial value of smoothed round trip time to be used
  334. when a new AX25 connection is created. The value is in milliseconds.
  335. The actual round trip time will be learned by measurement once the
  336. connection has been established.
  337. .NH 3
  338. ax25 kick <axcb>
  339. .LP
  340. Force a retransmission on the specified AX.25 control block.
  341. .NH 3
  342. ax25 maxframe [<count>]
  343. .LP
  344. Establish the maximum number of frames that will be allowed to remain
  345. unacknowledged at one time on new AX.25 connections. This number cannot
  346. be greater than 7.
  347. .NH 3
  348. ax25 mycall [<call>]
  349. .LP
  350. Display or set the local AX.25 address.  The standard format is used
  351. (eg. KA9Q-0 or WB6RQN-5).
  352. This command must be given before any \fBattach\fP commands
  353. using AX.25 mode are given.
  354. .NH 3
  355. ax25 paclen [<size>]
  356. .LP
  357. Limit the size of I-fields on new AX.25 connections.  If IP
  358. datagrams or fragments larger than this are transmitted, they will be
  359. transparently fragmented at the AX.25 level, sent as a series of I
  360. frames, and reassembled back into a complete IP datagram or fragment at
  361. the other end of the link. To have any effect on IP datagrams,
  362. this parameter should be less than or equal to
  363. the MTU of the associated interface.
  364. .NH 3
  365. ax25 pthresh [<size>]
  366. .LP
  367. Display or set the poll threshold to be used for new AX.25 Version 2
  368. connections.  The poll threshold controls retransmission behavior as
  369. follows. If the oldest unacknowledged I-frame size is less than the poll
  370. threshold, it will be sent with the poll (P) bit set if a timeout occurs.
  371. If the oldest unacked I-frame size is equal to or greater than the
  372. threshold, then a RR or RNR frame, as appropriate, with the poll bit set
  373. will be sent if a timeout occurs.
  374. .LP
  375. The idea behind the poll threshold is that the extra time needed to send a
  376. "small" I-frame instead of a supervisory frame when polling after a timeout
  377. is small, and since there's a good chance the I-frame will have to be sent
  378. anyway (i.e., if it were lost previously) then you might as well send it as
  379. the poll. But if the I-frame is large, send a supervisory (RR/RNR) poll
  380. instead to determine first if retransmitting the oldest unacknowledged
  381. I-frame is necessary; the timeout might have been caused by a lost
  382. acknowledgement.  This is obviously a tradeoff, so experiment with the
  383. poll threshold setting. The default is 128 bytes, one half the default
  384. value of \fBpaclen\fP.
  385. .NH 3
  386. ax25 reset <axcb>
  387. .LP
  388. Delete the AX.25 connection control block at the specified address.
  389. .NH 3
  390. ax25 retry [<count>]
  391. .LP
  392. Limit the number of successive unsuccessful retransmission attempts on
  393. new AX.25 connections. If this limit is exceeded, link re-establishment
  394. is attempted. If this fails \fBretry\fP times, then the connection
  395. is abandoned and all queued data is deleted.
  396. .NH 3
  397. ax25 route
  398. .LP
  399. Display the AX.25 routing table that
  400. specifies the digipeaters to be used in reaching a given station.
  401. .NH 4
  402. ax25 route add <target> [digis ... ]
  403. .LP
  404. Add an entry to the AX.25 routing table.  An automatic \fBax25
  405. route add\fP is executed if digipeaters are specified in an AX25 \fBconnect\fP
  406. command, or if a connection is received from a remote station via
  407. digipeaters. Such automatic routing table entries won't override locally
  408. created entries, however.
  409. .NH 4
  410. ax25 route drop <target>
  411. .LP
  412. Drop an entry from the AX.25 routing table.
  413. .NH 3
  414. ax25 status [<axcb>]
  415. .LP
  416. Without an argument, display a one-line summary of each AX.25 control block.
  417. If the address of a particular control block is specified, the contents of
  418. that control block are dumped in more detail. Note that the send queue units
  419. are frames, while the receive queue units are bytes.
  420. .NH 3
  421. ax25 t3 [<milliseconds>]
  422. .LP
  423. Display or set the AX.25 idle "keep alive" timer. Value is in milliseconds.
  424. .NH 3
  425. ax25 version [1 | 2]
  426. .LP
  427. Display or set the version of the AX.25 protocol to attempt to use on
  428. new connections. The default is 1 (the version
  429. that does not use the poll/final bits).
  430. .NH 3
  431. ax25 window [<size>]
  432. .LP
  433. Set the number of bytes that can be pending on an AX.25 receive queue
  434. beyond which I frames will be answered with RNR (Receiver Not Ready)
  435. responses.  This presently applies only to suspended interactive AX.25
  436. sessions, since incoming I-frames containing network (IP, NET/ROM) packets
  437. are always processed immediately and are not placed on the receive queue.
  438. However, when an AX.25 connection carries both interactive
  439. and network packet traffic, an RNR generated because of
  440. backlogged interactive traffic will also stop network
  441. packet traffic from being sent.
  442. .NH 2
  443. cd [<dirname>]
  444. .LP
  445. Change the current working directory, and display the new setting.
  446. Without an argument, \fBcd\fP simply displays the current directory
  447. without change.
  448. The \fBpwd\fP command is an alias for \fBcd\fP.
  449. .NH 2
  450. close [<session>]
  451. .LP
  452. Close the specified session; without an argument, close the current session.
  453. On an AX.25 session, this command initiates a disconnect.  On a FTP or
  454. Telnet session, this command sends a FIN (i.e., initiates a close) on the
  455. session's TCP connection.  This is an alternative to asking the remote
  456. server to initiate a close (\fBQUIT\fP to FTP, or the logout command appropriate
  457. for the remote system in the case of Telnet).  When either FTP or Telnet
  458. sees the incoming half of a TCP connection close, it automatically responds
  459. by closing the outgoing half of the connection.  Close is more graceful than
  460. the \fBreset\fP command, in that it is less likely to leave the remote TCP in a
  461. "half-open" state.
  462. .NH 2
  463. connect <iface> <callsign> [<digipeater> ... ]
  464. .LP
  465. Initiate a "vanilla" AX.25 session to the specified call sign using the
  466. specified interface. Data sent on this session goes out in
  467. conventional AX.25 packets with no upper layer protocol.  The de-facto
  468. presentation standard format is used, in that each packet holds one line
  469. of text, terminated by a carriage return.  A single AX.25 connection may
  470. be used for terminal-to-terminal, IP and NET/ROM traffic.
  471. The three types of data are automatically separated by their
  472. AX.25 Level 3 Protocol IDs.
  473. .LP
  474. Up to 7 optional digipeaters may be given; note that the word \fBvia\fP is NOT
  475. needed. If digipeaters are specified, they are automatically added to the
  476. AX25 routing table as though the \fBax25 route add\fP command had been given
  477. before issuing the \fBconnect\fP command.
  478. .NH 2
  479. delete <filename>
  480. .LP
  481. Delete a \fBfilename\fP in the current working directory.
  482. .NH 2
  483. detach <iface>
  484. .LP
  485. Detach a previously attached interface from the system. All IP routing
  486. table entries referring to this interface are deleted, and forwarding
  487. references by any other interface to this interface are removed.
  488. .NH 2
  489. dialer <iface> <seconds> <hostid> <pings> <dialer-file>
  490. .LP
  491. Setup an autodialer session for the interface.
  492. Whenever the interface is idle for the interval in <seconds>,
  493. the autodialer will ping the <hostid>.
  494. If there is no answer after <pings> attempts,
  495. the autodialer will execute the special commands contained in the <dialer-file>.
  496. .LP
  497. If the interval in <seconds> is zero,
  498. a previous dialer command process will be removed.
  499. If the number of <pings> is zero,
  500. the <dialer-file> will be executed without pinging the <hostid>.
  501. .LP
  502. The file may have any valid name,
  503. and must be located in the configuration directory
  504. (see the \fBInstallion\fP section).
  505. The commands in the file are described in the \fBDialer Subcommands\fP chapter.
  506. .NH 2
  507. dir [<dirname>]
  508. .LP
  509. List the contents of the specified directory on the console. If no argument
  510. is given, the current directory is listed. Note that this command works
  511. by first listing the directory into a temporary file, and then creating
  512. a \fBmore\fP session to display it. After this completes, the temporary
  513. file is deleted.
  514. .NH 2
  515. disconnect [<session #>]
  516. .LP
  517. An alias for the \fBclose\fP command (for the benefit of AX.25 users).
  518. .NH 2
  519. domain ...
  520. .LP
  521. These commands are used for access to the Domain Name Service.
  522. .NH 3
  523. domain addserver <hostid>
  524. .LP
  525. Add one or more domain name server(s) to the list of name servers.
  526. .NH 3
  527. domain dropserver <hostid>
  528. .LP
  529. Remove one or more domain name server(s) from the list of name servers.
  530. .NH 3
  531. domain listservers
  532. .LP
  533. List the currently configured domain name servers, along with statistics
  534. on how many queries and replies have been exchanged with each one,
  535. response times, etc.
  536. .NH 3
  537. domain query <hostid>
  538. .LP
  539. Send a query to a domain server asking for all resource records
  540. associated with this <hostid>, and list the records.
  541. .NH 3
  542. domain retry [<count>]
  543. .LP
  544. Display or set the number of attempts to reach each server on the list
  545. during one call to the resolver.
  546. If this count is exceeded,
  547. a failure indication is returned.
  548. If set to 0, the list will cycle forever;
  549. this may be useful for unattended operation.
  550. The default is 3.
  551. .NH 3
  552. domain suffix [<domain suffix>]
  553. .LP
  554. Display or specify the default domain name suffix to be appended to
  555. a host name when it contains no periods. For example, if the suffix is
  556. set to \fBampr.org\fP and the user enters \fBtelnet ka9q\fP, the domain
  557. resolver will attempt to find \fBka9q.ampr.org\fP. If the host name being
  558. sought contains one or more periods, however, the default suffix is NOT
  559. applied (eg. \fBtelnet foo.bar\fP would NOT be turned into
  560. \fBfoo.bar.ampr.org\fP).
  561. .NH 3
  562. domain trace [on | off]
  563. .LP
  564. Display or set the flag controlling the tracing of domain server
  565. requests and responses. Trace messages will be seen only if a domain name
  566. being sought is not found in the local cache file, \fBdomain.txt\fP.
  567. .NH 3
  568. domain cache ...
  569. .LP
  570. These commands are used for the use of the resource record file \fBdomain.txt\fP,
  571. and the local memory cache.
  572. .NH 4
  573. domain cache clean [on | off]
  574. .LP
  575. Display or set the flag controlling the removal of resource records
  576. from the \fBdomain.txt\fP file whose time-to-live has reached zero.
  577. .LP
  578. When clean is off (the default), expired records will be retained;
  579. if no replacement can be obtained from another domain name server,
  580. these records will continue to be used.
  581. .LP
  582. When clean is on, expired records will be removed from the file
  583. whenever any new record is added to the file.
  584. .NH 4
  585. domain cache list
  586. .LP
  587. List the current contents of the local memory cache.
  588. .NH 4
  589. domain cache size [<count>]
  590. .LP
  591. Display or set the nominal maximum size of the local memory cache.
  592. The default is 20.
  593. .LP
  594. (Note: The cache may be temporarily larger when waiting for new records
  595. to be written to the \fBdomain.txt\fP file.)
  596. .NH 4
  597. domain cache wait [<seconds>]
  598. .LP
  599. Display or set the interval in seconds to wait for additional activity
  600. before updating the \fBdomain.txt\fP file.  The default is 300 seconds
  601. (5 minutes).
  602. .NH 2
  603. echo [accept | refuse]
  604. .LP
  605. Display or set the flag controlling client Telnet's response to a
  606. remote WILL ECHO offer.
  607. .LP
  608. The Telnet presentation protocol specifies that in the absence of a negotiated
  609. agreement to the contrary, neither end echoes data received from the other.
  610. In this mode, a Telnet client session echoes keyboard input locally and nothing
  611. is actually sent until a carriage return is typed. Local line editing is also
  612. performed: backspace deletes the last character typed, while control-U deletes
  613. the entire line.
  614. .LP
  615. When communicating from keyboard to keyboard the standard local echo mode is
  616. used, so the setting of this parameter has no effect. However, many
  617. timesharing systems (eg. UNIX) prefer to do their own echoing of typed input.
  618. (This makes screen editors work right, among other things). Such systems send
  619. a Telnet WILL ECHO offer immediately upon receiving an incoming Telnet
  620. connection request. If \fBecho accept\fP is in effect, a client Telnet
  621. session will
  622. automatically return a DO ECHO response. In this mode, local echoing and
  623. editing is turned off and each key stroke is sent immediately (subject to the
  624. Nagle tinygram algorithm in TCP).  While this mode is just fine across an
  625. Ethernet, it is clearly inefficient and painful across slow paths like packet
  626. radio channels. Specifying \fBecho refuse\fP causes an incoming WILL ECHO
  627. offer to be answered with a DONT ECHO; the client Telnet session remains
  628. in the local echo mode.  Sessions already in the remote echo mode are
  629. unaffected. (Note: Berkeley Unix has a bug in that it will still echo input
  630. even after the client has refused the WILL ECHO offer. To get around this
  631. problem, enter the \fBstty -echo\fP command to the shell once you have
  632. logged in.)
  633. .NH 2
  634. eol [unix | standard]
  635. .LP
  636. Display or set Telnet's end-of-line behavior when in remote echo mode.
  637. In standard mode, each key is sent as-is. In unix mode, carriage returns
  638. are translated to line feeds.  This command is not necessary with all UNIX
  639. systems; use it only when you find that a particular system responds to
  640. line feeds but not carriage returns.  Only SunOS release 3.2 seems to
  641. exhibit this behavior; later releases are fixed.
  642. .NH 2
  643. escape [<char>]
  644. .LP
  645. Display or set the current command-mode escape character in hex.
  646. (This command is not provided on the IBM-PC; on the PC, the escape char is
  647. always F10.)
  648. .NH 2
  649. etherstat
  650. .LP
  651. Display 3-Com Ethernet controller statistics (if configured).
  652. .NH 2
  653. exit
  654. .LP
  655. Exit the \fBnet.exe\fP program and return to MS-DOS.
  656. .NH 2
  657. finger <user@hostid> [<user@hostid> ...]
  658. .LP
  659. Issue a network finger request for user \fBuser\fP at host \fBhostid\fP. This
  660. creates a client session which may be interrupted, resumed, reset, etc,
  661. just like a Telnet client session.
  662. .NH 2
  663. ftp <hostid>
  664. .LP
  665. Open an FTP control channel to the specified remote host and enter converse
  666. mode on the new session.  Responses from the remote server are displayed
  667. directly on the screen. See the \fBFTP Subcommands\fP chapter for descriptions
  668. of the commands available in a FTP session.
  669. .NH 2
  670. help
  671. .LP
  672. Display a brief summary of top-level commands.
  673. .NH 2
  674. hop ...
  675. .LP
  676. These commands are used to test the connectivity of the network.
  677. .NH 3
  678. hop check <hostid>
  679. .LP
  680. Initiate a \fIhopcheck\fP session to the specified host. This uses a series
  681. of UDP "probe" packets with increasing IP TTL fields to determine the
  682. sequence of gateways in the path to the specified destination. This
  683. function is patterned after the UNIX \fItraceroute\fP facility.
  684. .LP
  685. ICMP message tracing should be turned off before this command is
  686. executed (see the \fBicmp trace\fP command).
  687. .NH 3
  688. hop maxttl [<hops>]
  689. .LP
  690. Display or set the maximum TTL value to be used in hop check sessions.
  691. This effectively bounds the radius of the search.
  692. .NH 3
  693. hop maxwait [<seconds>]
  694. .LP
  695. Display or set the maximum interval that a hopcheck session
  696. will wait for responses at each stage of the trace. The default is 5 seconds.
  697. .NH 3
  698. hop queries [<count>]
  699. .LP
  700. Display or set the number of UDP probes that will be sent at each stage
  701. of the trace. The default is 3.
  702. .NH 3
  703. hop trace [on | off]
  704. .LP
  705. Display or set the flag that controls the display of additional information
  706. during a hop check session.
  707. .NH 2
  708. hostname [<name>]
  709. .LP
  710. Display or set the local host's name. By convention this should be the same
  711. as the host's primary domain name. This string
  712. is used only in the greeting messages
  713. of the various network servers;
  714. note that it does NOT set the system's IP address.
  715. .LP
  716. If <name> is the same as an <iface> (see the \fBAttach commands\fP chapter),
  717. this command will search for a CNAME domain resource record
  718. which corresponds to the IP address of the <iface>.
  719. .NH 2
  720. hs
  721. .LP
  722. Display statistics about the HS high speed HDLC driver (if configured
  723. and active).
  724. .NH 2
  725. icmp ...
  726. .LP
  727. These commands are used for the Internet Control Message Protocol service.
  728. .NH 3
  729. icmp echo [on | off]
  730. .LP
  731. Display or set the flag controlling
  732. the asynchronous display of ICMP Echo Reply packets.
  733. This flag must be on for one-shot pings to work (see the \fBping\fP command.)
  734. .NH 3
  735. icmp status
  736. .LP
  737. Display statistics about the
  738. Internet Control Message Protocol (ICMP), including the number of ICMP
  739. messages of each type sent or received. 
  740. .NH 3
  741. icmp trace [on | off]
  742. .LP
  743. Display or set the flag controlling
  744. the display of ICMP error messages. These informational
  745. messages are generated by Internet routers in response to routing,
  746. protocol or congestion problems. This option should be turned
  747. off before using the \fBhop check\fP facility because it
  748. relies on ICMP Time Exceeded messages, and the asynchronous
  749. display of these messages will be mingled with \fBhop check\fP command output.
  750. .NH 2
  751. ifconfig
  752. .LP
  753. Display a list of interfaces, with a short status for each.
  754. .NH 3
  755. ifconfig <iface>
  756. .LP
  757. Display an extended status of the interface.
  758. .NH 3
  759. ifconfig <iface> broadcast <address>
  760. .LP
  761. Set the broadcast address for the interface.
  762. The <address> takes the form of an IP address
  763. with 1's in the host part of the address.
  764. This is related to the \fBnetmask\fP sub-command.
  765. See also the \fBarp\fP command.
  766. .NH 3
  767. ifconfig <iface> encapsulation <name>
  768. .LP
  769. Not fully implemented.
  770. .NH 3
  771. ifconfig <iface> forward <forward-iface>
  772. .LP
  773. Set a forwarding interface for multiple channel interfaces.
  774. To remove the forward, set <forward-iface> to <iface>.
  775. .NH 3
  776. ifconfig <iface> ipaddress <hostid>
  777. .LP
  778. Set the IP address for this interface.
  779. It is standard Internet practice that each interface has its own address.
  780. For hosts with only one interface, the interface address is usually the
  781. same as the host address.
  782. See also the \fBhostname\fP and \fBip address\fP commands.
  783. .NH 3
  784. ifconfig <iface> linkaddress <hardware-dependant>
  785. .LP
  786. Set the hardware dependant address for this interface.
  787. .NH 3
  788. ifconfig <iface> mtu <mtu>
  789. .LP
  790. Set the MTU for this interface.
  791. See the \fBSetting ... MTU, MSS and Window\fP chapter for more information.
  792. .NH 3
  793. ifconfig <iface> netmask <address>
  794. .LP
  795. Set the sub-net mask for this interface.
  796. The <address> takes the form of an IP address
  797. with 1's in the network and subnet parts of the address,
  798. and 0's in the host part of the address.
  799. This is related to the \fBbroadcast\fP sub-command.
  800. See also the \fBroute\fP command.
  801. .NH 3
  802. ifconfig <iface> rxbuf <?>
  803. .LP
  804. Not yet implemented.
  805. .NH 2
  806. ip ...
  807. .LP
  808. These commands are used for the Internet Protocol service.
  809. .NH 3
  810. ip address [<hostid>]
  811. .LP
  812. Display or set the default local IP address. This command must be given before
  813. an \fBattach\fP command if it is to be used as the default IP address for
  814. the interface.
  815. .NH 3
  816. ip rtimer [<seconds>]
  817. .LP
  818. Display or set the IP reassembly timeout. The default is 30 seconds.
  819. .NH 3
  820. ip status
  821. .LP
  822. Display Internet Protocol (IP) statistics, such as total packet counts
  823. and error counters of various types.
  824. .NH 3
  825. ip ttl [<hops>]
  826. .LP
  827. Display or set the time-to-live value placed in each outgoing IP datagram.
  828. This limits the number of switch hops the datagram will be allowed to
  829. take. The idea is to bound the lifetime of the packet should it become caught
  830. in a routing loop, so make the value slightly larger than the number of
  831. hops across the network you expect to transit packets.
  832. The default is set at compilation time to the official recommended value
  833. for the Internet.
  834. .NH 2
  835. isat [on | off]
  836. .LP
  837. Display or set the AT flag.
  838. Currently, there is no sure-fire way to determine the type of clock-chip
  839. being used.  If an AT type clock is in use, this command will allow
  840. measurement of time in milliseconds, rather than clock ticks
  841. (55 milliseconds per clock tick).
  842. .NH 3
  843. kick [<session>]
  844. .LP
  845. Kick all sockets associated with a session;
  846. if no argument is given, kick the current session.
  847. Performs the same function as the \fBax25 kick\fP and \fBtcp kick\fP commands,
  848. but is easier to type.
  849. .NH 2
  850. log [stop | <filename>]
  851. .LP
  852. Display or set the \fBfilename\fP for logging server sessions. If
  853. \fBstop\fP is given as the argument, logging is terminated
  854. (the servers themselves are unaffected).
  855. If a file name is given as an argument, server session log
  856. entries will be appended to it.
  857. .NH 2
  858. mbox
  859. .LP
  860. Display the status of the mailbox server system (if configured).
  861. .NH 2
  862. memory ...
  863. .LP
  864. These commands are used for memory allocation.
  865. .NH 3
  866. memory free
  867. .LP
  868. Display the storage allocator free list. Each entry consists of a
  869. starting address, in hex, and a size, in decimal bytes.
  870. .NH 3
  871. memory sizes
  872. .LP
  873. Display a histogram of storage allocator request sizes. Each histogram
  874. bin is a binary order of magnitude (i.e., a factor of 2).
  875. .NH 3
  876. memory status
  877. .LP
  878. Display a summary of storage allocator statistics. The first line
  879. shows the base address of the heap, its total size, the amount of heap
  880. memory available in bytes and as a percentage of the total heap size,
  881. and the amount of memory left over (i.e., not placed on the heap at startup)
  882. and therefore available for \fBshell\fP subcommands.
  883. .LP
  884. The second line shows the total number of calls to allocate and free blocks
  885. of memory, the difference of these two values (i.e., the number of allocated
  886. blocks outstanding), the number of allocation requests that were denied
  887. due to lack of memory, and the number of calls to free() that attempted to
  888. free garbage
  889. (eg. by freeing the same block twice or freeing a garbled pointer).
  890. .LP
  891. The third line shows the number of calls to malloc and free that occurred
  892. with interrupts off. In normal situations these values should be zero.
  893. The fourth line shows statistics for the special pool of fixed-size buffers
  894. used to satisfy requests for memory at interrupt time. The variables
  895. shown are the number of buffers currently in the pool, their size, and
  896. the number of requests that failed due to exhaustion of the pool.
  897. .NH 2
  898. mkdir <dirname>
  899. .LP
  900. Create a sub-directory in the current working directory.
  901. .NH 2
  902. mode <iface> [vc | datagram]
  903. .LP
  904. Control the default transmission mode on the specified AX.25 interface. 
  905. In \fBdatagram\fP mode, IP packets are encapsulated in AX.25 UI frames and
  906. transmitted without any other link level mechanisms, such as connections
  907. or acknowledgements. 
  908. .LP
  909. In \fBvc\fP (virtual circuit) mode, IP packets are encapsulated in AX.25 I
  910. frames and are acknowledged at the link level according to the AX.25
  911. protocol.  Link level connections are opened if necessary.
  912. .LP
  913. In both modes, ARP is used to map IP to AX.25 addresses.  The defaults
  914. can be overridden with the type-of-service (TOS) bits in the IP header. 
  915. Turning on the "reliability" bit causes I frames to be used, while
  916. turning on the "low delay" bit uses UI frames.  (The effect of turning
  917. on both bits is undefined and subject to change).
  918. .LP
  919. In both modes, IP-level fragmentation is done if the datagram is larger
  920. than the interface  MTU.  In virtual circuit mode, however, the resulting
  921. datagram (or fragments) is further fragmented at the AX.25 layer if it
  922. (or they) are still larger than the AX.25 \fBpaclen\fP parameter. In AX.25
  923. fragmentation, datagrams are broken into several I frames and reassembled
  924. at the receiving end before being passed to IP. This is preferable to
  925. IP fragmentation whenever possible because of decreased overhead (the IP
  926. header isn't repeated in each fragment) and increased robustness (a
  927. lost fragment is immediately retransmitted by the link layer).
  928. .NH 2
  929. more <file> [<file> ...]
  930. .LP
  931. Display the specified file(s) a screen at a time. To proceed to the next
  932. screen, press the space bar; to cancel the display, hit the 'q' key.
  933. The \fBmore\fP command creates a session that you can suspend and resume
  934. just like any other session.
  935. .NH 2
  936. param <iface> [<param> ...]
  937. .LP
  938. Invoke a device-specific control routine.  On a KISS TNC
  939. interface, this sends control packets to the TNC.  Data bytes are
  940. treated as decimal.  For example, \fBparam ax0 1 255 \fP will set the keyup
  941. timer (type field = 1) on the KISS TNC configured as ax0 to 2.55 seconds
  942. (255 x .01 sec).  On a SLIP interface, the \fBparam\fP command allows the baud
  943. rate to be read (without arguments) or set.  The implementation of this
  944. command for the various interface drivers is incomplete and subject to
  945. change. 
  946. .NH 2
  947. ping <hostid> [<length> [<seconds> [<incflag>]]]
  948. .LP
  949. Ping (send ICMP Echo Request packets to) the specified host. By default
  950. the data field contains only a small timestamp to aid in determining
  951. round trip time; if the optional \fBlength\fP argument is given,
  952. the appropriate number of data bytes (consisting of hex 55) are added to the
  953. ping packets.
  954. .LP
  955. If interval is specified, pings will be repeated indefinitely
  956. at the specified number of seconds;
  957. otherwise a single, "one shot" ping is done.
  958. Responses to one-shot pings appear asynchronously on the command screen,
  959. while repeated pings create a session that may be suspended and resumed.
  960. Pinging continues until the session is manually reset.
  961. .LP
  962. The \fBincflag\fP option causes a repeated ping to increment the
  963. target IP address for each ping; it is an experimental feature for searching
  964. blocks of IP addresses for active hosts.
  965. .NH 2
  966. ppp ...
  967. .LP
  968. These commands are used for Point to Point Protocol interfaces.
  969. .LP
  970. This implementation of PPP is designed to be as complete as possible.
  971. Because of this, the number of options can be rather daunting.
  972. However, a typical PPP configuration might include the following commands:
  973. .DS
  974. attach asy 0x3f8 4 ppp pp0 4096 1500 9600
  975. dial pp0 30 <hostid> 3 dialer.pp0
  976. #
  977. ppp pp0 lcp local accm 0
  978. ppp pp0 lcp local compress address on
  979. ppp pp0 lcp local compress protocol on
  980. ppp pp0 lcp local magic on
  981. ppp pp0 lcp open active
  982. #
  983. ppp pp0 ipcp local compress tcp 16 1
  984. ppp pp0 ipcp open active
  985. #
  986. route add default pp0
  987. .DE
  988. .NH 3
  989. ppp <iface>
  990. .LP
  991. Display the status of the PPP interface.
  992. .NH 3
  993. ppp <iface> lcp ...
  994. .LP
  995. These commands are used for the LCP [Link Control Protocol]
  996. configuration.
  997. .NH 4
  998. ppp <iface> lcp close
  999. .LP
  1000. Shutdown the PPP interface.
  1001. .NH 4
  1002. ppp <iface> lcp local ...
  1003. .LP
  1004. These commands control the configuration of the local side of the link.
  1005. If an option is specified, the parameters will be used
  1006. as the initial values in configuration requests.
  1007. If not specified, that option will not be requested.
  1008. .LP
  1009. For each of these options,
  1010. the \fBallow\fP parameter will permit the remote
  1011. to include that option in its response,
  1012. even when the option is not included in the request.
  1013. By default, all options are allowed.
  1014. .NH 5
  1015. ppp <iface> lcp local accm [ <bitmap> | allow [on | off] ]
  1016. .LP
  1017. Display or set the Async Control Character Map.
  1018. The default is 0xffffffff.
  1019. .NH 5
  1020. ppp <iface> lcp local authenticate [ pap | none | allow [on | off] ]
  1021. .LP
  1022. Display or set the authentication protocol.
  1023. The default is \fBnone\fP.
  1024. .NH 5
  1025. ppp <iface> lcp local compress address/control [ on | off | allow [on | off] ]
  1026. .LP
  1027. Display or set the option to compress the address and control fields of
  1028. the PPP HLDC-like header.
  1029. This is generally desirable for slow asynchronous links,
  1030. and undesirable for fast or synchronous links.
  1031. The default is off.
  1032. .NH 5
  1033. ppp <iface> lcp local compress protocol [ on | off | allow [on | off] ]
  1034. .LP
  1035. Display or set the option to compress the protocol field of
  1036. the PPP HLDC-like header.
  1037. This is generally desirable for slow asynchronous links,
  1038. and undesirable for fast or synchronous links.
  1039. The default is off.
  1040. .NH 5
  1041. ppp <iface> lcp local magic [ on | off | <value> | allow [on | off] ]
  1042. .LP
  1043. Display or set the initial Magic Number.
  1044. The default is off (zero).
  1045. .NH 5
  1046. ppp <iface> lcp local mru [ <size> | allow [on | off] ]
  1047. .LP
  1048. Display or set the Maximum Receive Unit.
  1049. The default is 1500.
  1050. .NH 5
  1051. ppp <iface> lcp local default
  1052. .LP
  1053. Reset the options to their default values.
  1054. .NH 4
  1055. ppp <iface> lcp open active | passive
  1056. .LP
  1057. Wait for the physical layer to come up.
  1058. If \fBactive\fP, initiate configuration negotiation.
  1059. If \fBpassive\fP, wait for configuration negotiation from the remote.
  1060. .NH 4
  1061. ppp <iface> lcp remote ...
  1062. .LP
  1063. These commands control the configuration of the remote side of the link.
  1064. The options are identical to those of the local side.
  1065. If an option is specified, the parameters will be used
  1066. in responses to the remote's configuration requests.
  1067. If not specified, that option will be accepted if it is allowed.
  1068. .LP
  1069. For each of these options,
  1070. the \fBallow\fP parameter will permit the remote
  1071. to specify that option in its request.
  1072. By default, all options are allowed.
  1073. .NH 4
  1074. ppp <iface> lcp timeout [<seconds>]
  1075. .LP
  1076. Display or set the interval to wait between configuration
  1077. or termination attempts.
  1078. The default is 3 seconds.
  1079. .NH 4
  1080. ppp <iface> lcp try ...
  1081. .LP
  1082. These commands are used for the various counters.
  1083. .NH 5
  1084. ppp <iface> lcp try configure [<count>]
  1085. .LP
  1086. Display or set the number of configuration requests sent.
  1087. The default is 10.
  1088. .NH 5
  1089. ppp <iface> lcp try failure [<count>]
  1090. .LP
  1091. Display or set the number of bad configuration requests allowed from the remote.
  1092. The default is 5.
  1093. .NH 5
  1094. ppp <iface> lcp try terminate [<count>]
  1095. .LP
  1096. Display or set the number of termination requests sent before shutdown.
  1097. The default is 2.
  1098. .NH 3
  1099. ppp <iface> ipcp ...
  1100. .LP
  1101. These commands are used for the IPCP [Internet Protocol Control Protocol]
  1102. configuration.
  1103. .LP
  1104. The \fBclose, open, timeout\fP and \fBtry\fP sub-commands
  1105. are identical to the LCP (described above).
  1106. .NH 4
  1107. ppp <iface> ipcp local ...
  1108. .LP
  1109. These commands control the configuration of the local side of the link.
  1110. If an option is specified, the parameters will be used
  1111. as the initial values in configuration requests.
  1112. If not specified, that option will not be requested.
  1113. .LP
  1114. For each of these options,
  1115. the \fBallow\fP parameter will permit the remote
  1116. to include that option in its response,
  1117. even when the option is not included in the request.
  1118. By default, all options are allowed.
  1119. .NH 5
  1120. ppp <iface> ipcp local address [ <hostid> | allow [on | off] ]
  1121. .LP
  1122. Display or set the local address for negotiation purposes.
  1123. If an address of 0 is specified,
  1124. the other side of the link will supply the address.
  1125. By default, no addresses are negotiated.
  1126. .NH 5
  1127. ppp <iface> ipcp local compress [ tcp <slots> [<flag>] | none | allow [on | off] ]
  1128. .LP
  1129. Display or set the compression protocol.
  1130. The default is \fBnone\fP.
  1131. .LP
  1132. The \fBtcp\fP <slots> specifies the number of "conversation" slots,
  1133. which must be 1 to 255.
  1134. (This may be limited at compilation time to a smaller number.)
  1135. A good choice is in the range 4 to 16.
  1136. .LP
  1137. The \fBtcp\fP <flag> is 0 (don't compress the slot number)
  1138. or 1 (OK to compress the slot number).
  1139. KA9Q can handle compressed slot numbers, so the default is 1.
  1140. .NH 4
  1141. ppp <iface> ipcp remote ...
  1142. .LP
  1143. These commands control the configuration of the remote side of the link.
  1144. The options are identical to those of the local side.
  1145. If an option is specified, the parameters will be used
  1146. in responses to the remote's configuration requests.
  1147. If not specified, that option will be accepted if it is allowed.
  1148. .LP
  1149. For each of these options,
  1150. the \fBallow\fP parameter will permit the remote
  1151. to specify that option in its request.
  1152. By default, all options are allowed.
  1153. .NH 3
  1154. ppp <iface> pap ...
  1155. .LP
  1156. These commands are used for the PAP [Password Authentication Protocol]
  1157. configuration.
  1158. .LP
  1159. The \fBtimeout\fP and \fBtry\fP sub-commands
  1160. are identical to the LCP (described above).
  1161. However, the terminate counter is unused.
  1162. .NH 4
  1163. ppp <iface> pap user [ <username> [<password>] ]
  1164. .LP
  1165. Display or set the username (the password may be set, but not displayed).
  1166. When the username is specified, but no password is supplied,
  1167. the \fBftpusers\fP file is searched for the password.
  1168. When a username/password is unknown or rejected,
  1169. a session will appear at the console to prompt for a new username/password.
  1170. .NH 3
  1171. ppp <iface> trace [<flags>]
  1172. .LP
  1173. Display or set the flags that control the logging of information
  1174. during PPP link configuration.
  1175. .LP
  1176. The flag value is 0 for none, 1 for basic, and 2 for general.
  1177. Values greater than 2 are usually not compiled,
  1178. and are described in the appropriate source files where they are defined.
  1179. .NH 2
  1180. ps
  1181. .LP
  1182. Display all current processes in the system. The fields are as follows:
  1183. .LP
  1184. \fBPID\fP - Process ID (the address of the process descriptor).
  1185. .LP
  1186. \fBSP\fP - The current value of the process stack pointer.
  1187. .LP
  1188. \fBstksize\fP - The size of the stack allocated to the process.
  1189. .LP
  1190. \fBmaxstk\fP - The apparent peak stack utilization of this process. This is
  1191. done in a somewhat heuristic fashion, so the numbers should be treated
  1192. as approximate. If this number reaches or exceeds the stksize figure,
  1193. the system is almost certain to crash; the \fBnet.exe\fP program
  1194. should be recompiled to give the process a larger allocation when it is started.
  1195. .LP
  1196. \fBevent\fP - The event this task is waiting for, if it is not runnable.
  1197. .LP
  1198. \fBfl\fP - Process status flags. There are three: I (Interrupts enabled),
  1199. W (Waiting for event) and S (Suspended). The I
  1200. flag is set whenever a task has executed a pwait() call (wait for
  1201. event) without first disabling hardware interrupts. Only tasks that
  1202. wait for hardware interrupt events will turn off this flag; this is
  1203. done to avoid critical sections and missed interrupts. The W flag
  1204. indicates that the process is waiting for an event; the \fBevent\fP
  1205. column will be non-blank. Note that although there may be several
  1206. runnable processes at any time (shown in the \fBps\fP listing as those
  1207. without the W flag and with blank event fields) only one
  1208. process is actually running at any one instant (The Refrigerator
  1209. Light Effect says that the \fBps\fP command is always the one running
  1210. when this display is generated.)
  1211. .NH 2
  1212. pwd [<dirname>]
  1213. .LP
  1214. An alias for the \fBcd\fP command.
  1215. .NH 2
  1216. record [off | <filename>]
  1217. .LP
  1218. Append to \fBfilename\fP all data received on the current
  1219. session.  Data sent on the current session is also written into the file
  1220. except for Telnet sessions in remote echo mode.  The command \fBrecord
  1221. off\fP stops recording and closes the file.
  1222. .NH 2
  1223. remote [-p <port>] [-k <key>] [-a <kickaddr>] <hostid> exit | reset | kick
  1224. .LP
  1225. Send a UDP packet to the specified host commanding it
  1226. to exit the \fBnet.exe\fP program, reset the processor,
  1227. or force a retransmission on TCP connections.  For this
  1228. command to be accepted, the remote system must be running the \fBremote\fP
  1229. server and the port number specified in the \fBremote\fP command must match
  1230. the port number given when the server was started on the remote system.
  1231. If the port numbers do not match, or if the remote server is not running
  1232. on the target system, the command packet is ignored.  Even if the
  1233. command is accepted there is no acknowledgement.
  1234. .LP
  1235. The \fBkick\fP command forces a retransmission timeout on all
  1236. TCP connections that the remote node may have with the local node.
  1237. If the -a option is used, connections to the specified host are
  1238. kicked instead. No key is required for the kick subcommand.
  1239. .LP
  1240. The \fBexit\fP and \fBreset\fP subcommands are mainly useful for
  1241. restarting the \fBnet.exe\fP program on a remote
  1242. unattended system after the configuration file has been updated.  The
  1243. remote system should invoke the \fBnet.exe\fP program automatically upon booting,
  1244. preferably in an infinite loop.  For example, under MS-DOS the boot disk
  1245. should contain the following in \fBautoexec.net\fP:
  1246. .DS
  1247. .ft CW
  1248. :loop
  1249. net
  1250. goto :loop
  1251. .ft P
  1252. .DE
  1253. .LP
  1254. .NH 2
  1255. remote -s <key>
  1256. .LP
  1257. The \fBexit\fP and \fBreset\fP subcommands of remote require a password.
  1258. The password is set
  1259. on a given system with the \fB-s\fP option, and it is specified in a command
  1260. to a remote system with the \fB-k\fP option. If no password is set with the
  1261. \fB-s\fP option, then the \fBexit\fP and \fBreset\fP subcommands are disabled.
  1262. .LP
  1263. Note that \fBremote\fP is an experimental feature in NOS; it is \fInot\fP
  1264. yet supported by any other TCP/IP implementation.
  1265. .NH 2
  1266. rename <oldfilename> <newfilename>
  1267. .LP
  1268. Rename \fBoldfilename\fP to \fBnewfilename\fP.
  1269. .NH 2
  1270. reset [<session>]
  1271. .LP
  1272. Reset the specified session; if no argument is given, reset the current
  1273. session.  This command should be used with caution since it does not
  1274. reliably inform the remote end that the connection no longer exists.  (In
  1275. TCP a reset (RST) message will be automatically generated should the remote
  1276. TCP send anything after a local reset has been done.  In AX.25 the DM
  1277. message performs a similar role.  Both are used to get rid of a lingering
  1278. half-open connection after a remote system has crashed.)
  1279. .NH 2
  1280. rip ...
  1281. .LP
  1282. These commands are used for the RIP service.
  1283. .NH 3
  1284. rip accept <gateway>
  1285. .LP
  1286. Remove the specified gateway from the RIP filter table, allowing future
  1287. broadcasts from that gateway to be accepted.
  1288. .NH 3
  1289. rip add <hostid> <seconds> [<flags>]
  1290. .LP
  1291. Add an entry to the RIP broadcast table. The IP routing table will be sent
  1292. to \fBhostid\fP every interval seconds. If
  1293. \fBflags\fP is specified as 1, then "split horizon" processing will
  1294. be performed
  1295. for this destination. That is, any IP routing table entries pointing to the
  1296. interface that will be used to send this update will be removed from the
  1297. update.  If split horizon processing is not specified, then all routing
  1298. table entries except those marked "private" will be sent in each update.
  1299. (Private entries are never sent in RIP packets).
  1300. .LP
  1301. Triggered updates are always done. That is, any change in the routing table
  1302. that causes a previously reachable destination to become unreachable will
  1303. trigger an update that advertises the destination with metric 15, defined to
  1304. mean "infinity".
  1305. .LP
  1306. Note that for RIP packets to be sent properly to a broadcast address, there
  1307. must exist correct IP routing and ARP table entries that will first steer
  1308. the broadcast to the correct interface and then place the correct link-level
  1309. broadcast address in the link-level destination field. If a standard IP
  1310. broadcast address convention is used (eg. 128.96.0.0 or 128.96.255.255)
  1311. then chances are you already have the necessary IP routing table entry, but
  1312. unusual subnet or cluster-addressed networks may require special attention.
  1313. However, an \fBarp add\fP command will be required to translate this address to
  1314. the appropriate link level broadcast address.  For example,
  1315. .sp
  1316. .DS I 0
  1317. .ft CW
  1318. arp add 128.96.0.0 ethernet ff:ff:ff:ff:ff:ff
  1319. .ft P
  1320. .DE
  1321. .sp
  1322. for an Ethernet network, and
  1323. .sp
  1324. .DS I 0
  1325. .ft CW
  1326. arp add 44.255.255.255 ax25 qst-0
  1327. .ft P
  1328. .DE
  1329. .sp
  1330. for an AX25 packet radio channel.
  1331. .NH 3
  1332. rip drop <dest>
  1333. .LP
  1334. Remove an entry from the RIP broadcast table.
  1335. .NH 3
  1336. rip merge [on | off]
  1337. .LP
  1338. This flag controls an experimental feature for consolidating redundant
  1339. entries in the IP routing table. When rip merging is enabled, the table is
  1340. scanned after processing each RIP update. An entry is considered redundant
  1341. if the target(s) it covers would be routed identically by a less "specific"
  1342. entry already in the table. That is, the target address(es) specified
  1343. by the entry in question must also match the target addresses of the
  1344. less specific entry and the two entries must have the same interface
  1345. and gateway fields. For example, if the routing table contains
  1346. .sp
  1347. .DS I 0
  1348. .ft CW
  1349. Dest            Len Interface    Gateway          Metric  P Timer  Use
  1350. 1.2.3.4         32  ethernet0    128.96.1.2       1       0 0      0
  1351. 1.2.3           24  ethernet0    128.96.1.2       1       0 0      0
  1352. .ft
  1353. .DE
  1354. .sp
  1355. then the first entry would be deleted as redundant since packets sent to
  1356. 1.2.3.4 will still be routed correctly by the second entry. Note that the
  1357. relative metrics of the entries are ignored.
  1358. .NH 3
  1359. rip refuse <gateway>
  1360. .LP
  1361. Refuse to accept RIP updates from the specified gateway by adding the
  1362. gateway to the RIP filter table. It may be later removed with the \fBrip
  1363. accept\fP command.
  1364. .NH 3
  1365. rip request <gateway>
  1366. .LP
  1367. Send a RIP Request packet to the specified gateway, causing it to reply
  1368. with a RIP Response packet containing its routing table.
  1369. .NH 3
  1370. rip status
  1371. .LP
  1372. Display RIP status, including a count of the number of packets sent
  1373. and received, the number of requests and responses, the number of
  1374. unknown RIP packet types, and the number of refused RIP updates from hosts
  1375. in the filter table. A list of the addresses and intervals
  1376. to which periodic RIP updates are being sent is also shown, along with
  1377. the contents of the filter table.
  1378. .NH 3
  1379. rip trace [0 | 1 | 2]
  1380. .LP
  1381. This variable controls the tracing of incoming and outgoing RIP packets.
  1382. Setting it to 0 disables all RIP tracing. A value of 1 causes changes
  1383. in the routing table to be displayed, while packets that cause no changes
  1384. cause no output. Setting the variable to 2 produces maximum output,
  1385. including tracing of RIP packets that cause no change in the routing table.
  1386. .NH 2
  1387. rmdir <dirname>
  1388. .LP
  1389. Remove a sub-directory from the current working directory.
  1390. .NH 2
  1391. route
  1392. .LP
  1393. With no arguments, \fBroute\fP displays the IP routing table.
  1394. .NH 3
  1395. route add <dest_hostid>[/bits] | default <iface> [<gateway_hostid> [<metric>]]
  1396. .LP
  1397. This command adds an entry to the routing table. It requires at least two
  1398. more arguments, the hostid of the target destination and the name of
  1399. the interface to which its packets should be sent.  If the destination is
  1400. not local, the gateway's hostid should also be specified. (If the interface
  1401. is a point-to-point link, then \fBgateway_hostid\fP may be omitted even if the
  1402. target is non-local because this field is only used to determine the
  1403. gateway's link level address, if any.  If the destination is directly
  1404. reachable, \fBgateway_hostid\fP is also unnecessary since the destination
  1405. address is used to determine the interface link address).
  1406. .LP
  1407. The optional \fB/bits\fP suffix to the destination host id specifies how
  1408. many leading bits in the host id are to be considered significant in the
  1409. routing comparisons.  If not specified, 32 bits (i.e., full significance) is
  1410. assumed.  With this option, a single routing table entry may refer to
  1411. many hosts all sharing a common bit string prefix in their IP addresses. 
  1412. For example, ARPA Class A, B and C networks would use suffixes of /8,
  1413. /16 and /24 respectively; the command
  1414. .DS I 0
  1415. .ft CW
  1416. route add 44/8 sl0 44.64.0.2
  1417. .ft P
  1418. .DE
  1419. .LP
  1420. causes any IP addresses beginning with "44" in the first 8 bits to be
  1421. routed to 44.64.0.2; the remaining 24 bits are "don't-cares".
  1422. .LP
  1423. When an IP address to be routed matches more than one entry in the routing
  1424. table, the entry with largest \fBbits\fP parameter (i.e., the "best" match)
  1425. is used. This allows individual hosts or blocks of hosts to be exceptions
  1426. to a more general rule for a larger block of hosts.
  1427. .LP
  1428. The special destination \fBdefault\fP is used to route datagrams to
  1429. addresses not matched by any other entries
  1430. in the routing table; it is equivalent to specifying a
  1431. \fB/bits\fP suffix of /0 to any destination hostid.  Care must be taken with
  1432. default entries since two nodes with default entries pointing at each
  1433. other will route packets to unknown addresses back and forth in a loop
  1434. until their time-to-live (TTL) fields expire.  (Routing loops for
  1435. specific addresses can also be created, but this is less likely to occur
  1436. accidentally).
  1437. .LP
  1438. Here are some examples of the \fBroute\fP command:
  1439. .DS I 0
  1440. .ft CW
  1441. # Route datagrams to IP address 44.0.0.3 to SLIP line #0.
  1442. # No gateway is needed because SLIP is point-to point.
  1443. route add 44.0.0.3 sl0 
  1444.  
  1445. # Route all default traffic to the gateway on the local Ethernet
  1446. # with IP address 44.0.0.1
  1447. route add default ec0 44.0.0.1
  1448.  
  1449. # The local Ethernet has an ARPA Class-C address assignment;
  1450. # route all IP addresses beginning with 192.4.8 to it
  1451. route add 192.4.8/24 ec0
  1452.  
  1453. # The station with IP address 44.0.0.10 is on the local AX.25 channel
  1454. route add 44.0.0.10 ax0
  1455. .ft P
  1456. .DE
  1457. .NH 3
  1458. route addprivate <dest hostid>[/bits] | default <iface> [<gateway hostid> [<metric>]]
  1459. .LP
  1460. This command is identical to \fBroute add\fP except that it also marks the new
  1461. entry as private; it will never be included in outgoing RIP updates.
  1462. .NH 3
  1463. route drop <dest hostid>
  1464. .LP
  1465. \fBroute drop\fP deletes an entry from the table. If a packet arrives for the
  1466. deleted address and a default route is in effect, it will be used.
  1467. .NH 2
  1468. session [<session #>]
  1469. .LP
  1470. Without arguments, displays the list of current sessions, including
  1471. session number, remote TCP or AX.25 address and the address of the TCP or
  1472. AX.25 control block.  An asterisk (*) is shown next to the current
  1473. session; entering a blank line at this point puts you in converse mode with
  1474. that session.  Entering a session number as an argument to the \fBsession\fP
  1475. command will put you in \fIconverse\fP mode with that session.  If the Telnet
  1476. server is enabled, the user is notified of an incoming request and a
  1477. session number is automatically assigned.  The user may then select the
  1478. session normally to converse with the remote user as though the session
  1479. had been locally initiated. 
  1480. .NH 2
  1481. shell
  1482. .LP
  1483. Suspends \fBnet.exe\fP and executes a sub-shell
  1484. ("command processor" under MS-DOS).
  1485. When the sub-shell exits, \fBnet.exe\fP resumes
  1486. (under MS-DOS, enter the \fBexit\fP command).
  1487. Background activity (FTP servers, etc) is also suspended
  1488. while the subshell executes. Note that this will fail unless there is
  1489. sufficient unused memory for the sub-shell and whatever command the user
  1490. tries to run.
  1491. .NH 2
  1492. smtp ...
  1493. .LP
  1494. These commands are used for the Simple Message Transport Protocol service
  1495. (that is, mail).
  1496. .NH 3
  1497. smtp gateway [<hostid>]
  1498. .LP
  1499. Displays or sets the host to be used as a "smart" mail relay. Any mail sent
  1500. to a host not in the host table will instead be sent to the gateway for
  1501. forwarding.
  1502. .NH 3
  1503. smtp kick
  1504. .LP
  1505. Run through the outgoing mail queue and attempt to deliver any pending mail.
  1506. This command allows the user to "kick" the mail system manually.
  1507. Normally, this command is periodically invoked by a timer
  1508. whenever \fBnet.exe\fP is running.
  1509. .NH 3
  1510. smtp maxclients [<count>]
  1511. .LP
  1512. Displays or sets the maximum number of simultaneous outgoing SMTP sessions
  1513. that will be allowed. The default is 10; reduce it if network congestion
  1514. is a problem.
  1515. .NH 3
  1516. smtp timer [<seconds>]
  1517. .LP
  1518. Displays or sets the interval between scans of the outbound
  1519. mail queue. For example, \fBsmtp timer 600\fP will cause the system to check
  1520. for outgoing mail every 10 minutes and attempt to deliver anything it finds,
  1521. subject of course to the \fBsmtp maxclients\fP limit. Setting a value of zero
  1522. disables
  1523. queue scanning altogether, note that this is the default!  This value is
  1524. recommended for stand alone IP gateways that never handle mail, since it
  1525. saves wear and tear on the floppy disk drive.
  1526. .NH 3
  1527. smtp trace [<value>]
  1528. .LP
  1529. Displays or sets the trace flag in the SMTP client, allowing you to
  1530. watch SMTP's conversations as it delivers mail.  Zero (the default)
  1531. disables tracing.
  1532. .NH 2
  1533. socket [<socket #>]
  1534. .LP
  1535. Without an argument, displays all active sockets, giving their index
  1536. and type, the address of the associated protocol control block and the
  1537. and owner process ID and name. If the index to an active socket is
  1538. supplied, the status display for the appropriate protocol is called.
  1539. For example, if the socket refers to a TCP connection, the display will
  1540. be that given by the \fBtcp status\fP command with the protocol control
  1541. block address.
  1542. .NH 2
  1543. start ax25 | discard | echo | ftp | netrom | remote | smtp | telnet | ttylink
  1544. .LP
  1545. Start the specified Internet server, allowing remote connection requests.
  1546. .NH 2
  1547. stop ax25 | discard | echo | ftp | netrom | remote | smtp | telnet | ttylink
  1548. .LP
  1549. Stop the specified Internet server, rejecting any further remote connect
  1550. requests. Existing connections are allowed to complete normally.
  1551. .NH 2
  1552. tcp ...
  1553. .LP
  1554. These commands are used for the Transmission Control Protocol service.
  1555. .NH 3
  1556. tcp irtt [<milliseconds>]
  1557. .LP
  1558. Display or set the initial round trip time estimate, in milliseconds, to be
  1559. used for new TCP connections until they can measure and adapt to the
  1560. actual value.  The default is 5000 milliseconds (5 seconds).
  1561. Increasing this when operating
  1562. over slow channels will avoid the flurry of retransmissions that would
  1563. otherwise occur as the smoothed estimate settles down at the correct
  1564. value. Note that this command should be given before servers are started in
  1565. order for it to have effect on incoming connections.
  1566. .LP
  1567. TCP also keeps a \fIcache\fP of measured round trip times and mean
  1568. deviations (MDEV) for current and recent destinations. Whenever a new
  1569. TCP connection is opened, the system first looks in this cache. If the
  1570. destination is found, the cached IRTT and MDEV values are used. If not,
  1571. the default IRTT value mentioned above is used, along with a MDEV of 0.
  1572. This feature is fully automatic, and it can improve performance greatly
  1573. when a series of connections are opened and closed to a given destination
  1574. (eg. a series of FTP file transfers or directory listings).
  1575. .NH 3
  1576. tcp kick <tcb_addr>
  1577. .LP
  1578. If there is unacknowledged
  1579. data on the send queue of the specified TCB, this command forces
  1580. an immediate retransmission. 
  1581. .NH 3
  1582. tcp mss [<size>]
  1583. .LP
  1584. Display or set the TCP Maximum Segment Size in bytes that will be sent on all
  1585. outgoing TCP connect request (SYN segments).  This tells the remote end the
  1586. size of the largest segment (packet) it may send. Changing MSS affects
  1587. only future connections; existing connections are unaffected.
  1588. .NH 3
  1589. tcp reset <tcb_addr>
  1590. .LP
  1591. Deletes the TCP control block at the specified address.
  1592. .NH 3
  1593. tcp rtt <tcb_addr> <milliseconds>
  1594. .LP
  1595. Replaces the automatically computed round trip time in the specified TCB
  1596. with the rtt in milliseconds.  This command is useful to speed up
  1597. recovery from a series of lost packets since it provides a manual bypass
  1598. around the normal backoff retransmission timing mechanisms. 
  1599. .NH 3
  1600. tcp status [<tcb_addr>]
  1601. .LP
  1602. Without arguments, displays several TCP-level statistics, plus a summary of
  1603. all existing TCP connections, including TCB address, send and receive queue
  1604. sizes, local and remote sockets, and connection state. If \fBtcb_addr\fP is
  1605. specified, a more detailed dump of the specified TCB is generated, including
  1606. send and receive sequence numbers and timer information.
  1607. .NH 3
  1608. tcp window [<size>]
  1609. .LP
  1610. Displays or sets the default receive window size in bytes to be used by TCP
  1611. when creating new connections. Existing connections are unaffected.
  1612. .NH 2
  1613. telnet <hostid>
  1614. .LP
  1615. Creates a Telnet session to the specified host and enters converse mode.
  1616. .NH 2
  1617. tip <iface>
  1618. .LP
  1619. Creates a \fBtip\fP session that
  1620. connects to the specified interface in "dumb terminal" mode.
  1621. The interface must have already been attached with the \fBattach\fP command.
  1622. Any packet
  1623. traffic (IP datagrams, etc) routed to the interface while this session
  1624. exists will be discarded.
  1625. To close a \fBtip\fP session, use the \fBreset\fP command. It
  1626. will then revert to normal \fBslip, nrs\fP or \fBkiss\fP mode operation.
  1627. .LP
  1628. This feature is primarily useful for manually establishing SLIP connections.
  1629. At present, only the built-in "com" ports can be used with this command.
  1630. .NH 2
  1631. trace [<iface> [off | <btio> [<tracefile>]]]
  1632. .LP
  1633. Controls packet tracing by the interface drivers. Specific bits enable
  1634. tracing of the various interfaces and the amount of information produced.
  1635. Tracing is controlled on a per-interface basis; without arguments, \fBtrace\fP
  1636. gives a list of all defined interfaces and their tracing status.
  1637. Output can be limited to a single interface by specifying it, and the
  1638. control flags can be change by specifying them as well. The flags are
  1639. given as a hexadecimal number which is interpreted as follows:
  1640. .DS I 0
  1641. .ft CW
  1642.     O - Enable tracing of output packets if 1, disable if 0
  1643.     I - Enable tracing of input packets if 1, disable if 0
  1644.     T - Controls type of tracing:
  1645.     0 - Protocol headers are decoded, but data is not displayed
  1646.     1 - Protocol headers are decoded, and data (but not the
  1647.         headers themselves) are displayed as ASCII characters,
  1648.         64 characters/line. Unprintable characters are displayed
  1649.         as periods.
  1650.     2 - Protocol headers are decoded, and the entire packet
  1651.         (headers AND data) is also displayed in hexadecimal
  1652.         and ASCII, 16 characters per line.
  1653.     B - Broadcast filter flag. If set, only packets specifically addressed
  1654.     to this node will be traced; broadcast packets will not be displayed.
  1655. .ft
  1656. .DE
  1657. If \fBtracefile\fP is not specified, tracing will be to the console.
  1658. .NH 2
  1659. udp status
  1660. .LP
  1661. Displays the status of all UDP receive queues.
  1662. .NH 2
  1663. upload [<filename>]
  1664. .LP
  1665. Opens \fBfilename\fP and sends it on the current session as though it were
  1666. typed on the terminal.
  1667. .NH 2
  1668. watch
  1669. .LP
  1670. Displays the current software stopwatch values, with min and max readings
  1671. for each. This facility allows a programmer to measure the execution time
  1672. of critical sections of code with microsecond resolution.
  1673. This command is supported only on the IBM PC, and the meaning of each
  1674. stopwatch value depends on where the calls have been inserted for test
  1675. purposes; the distribution copy of \fBnet.exe\fP usually has no stopwatch calls.
  1676. .NH 2
  1677. ?
  1678. .LP
  1679. Same as the \fBhelp\fP command.
  1680. .bp
  1681. .NH 1
  1682. Attach Commands
  1683. .LP
  1684. This chapter details the attach commands for the various hardware interface
  1685. drivers. Not all of these drivers may be configured into every \fBnet.exe\fP
  1686. binary; a list of the available types may be obtained by entering the
  1687. command \fBattach ?\fP.
  1688. .LP
  1689. Some parameters are accepted by several drivers. They are:
  1690. .NH 3
  1691. <bufsize>
  1692. .LP
  1693. For asynchronous devices (eg. COM ports operating in SLIP or NRS mode)
  1694. this parameter specifies the size of the receiver's ring buffer.
  1695. It should be large enough to hold incoming data at full line speed for
  1696. the longest time that the system may be busy in MS-DOS or the BIOS doing
  1697. a slow I/O operation (eg. to a floppy disk). A kilobyte is usually more
  1698. than sufficient.
  1699. .LP
  1700. For synchronous devices (eg. the \fBscc, hs, pc100, hapn\fP
  1701. and \fBdrsi\fP interfaces operating in HDLC mode),
  1702. the bufsize parameter specifies the largest packet
  1703. that may be received on the interface.  This should be set by mutual
  1704. agreement among stations sharing the channel. For standard AX.25 with a
  1705. maximum I-frame data size of 256 bytes, a value of 325 should provide an
  1706. adequate safety margin. On higher speed channels (eg. 56kb/s) larger
  1707. values (eg. 2K bytes) will provide much better performance and allow
  1708. full-sized Ethernet packets to be carried without fragmentation.
  1709. .NH 3
  1710. <ioaddr>
  1711. .LP
  1712. The base address of the interface's control registers, in hex.
  1713. .NH 3
  1714. <vector>
  1715. .LP
  1716. The interface's hardware interrupt (IRQ) vector, in hex.
  1717. .NH 3
  1718. <iface>
  1719. .LP
  1720. The name (an arbitrary character string)
  1721. to be assigned to this interface. It is used to refer to the
  1722. interface in \fBifconfig\fP and \fBroute\fP commands and in \fBtrace\fP output.
  1723. .NH 3
  1724. <mtu>
  1725. .LP
  1726. The Maximum Transmission Unit size, in bytes.  Datagrams
  1727. larger than this limit will be fragmented at the IP layer into smaller
  1728. pieces. For AX.25 UI frames, this limits the size of the information field.
  1729. For AX.25 I frames, however, the \fBax25 paclen\fP parameter is also
  1730. relevant.  If
  1731. the datagram or fragment is still larger than \fBpaclen\fP, it is also
  1732. fragmented at the AX.25 level (as opposed to the IP level) before
  1733. transmission.  (See the \fBax25 paclen\fP command for further information).
  1734. .NH 3
  1735. <speed>
  1736. .LP
  1737. The speed in bits per second (eg. 2400).
  1738. .NH 2
  1739. attach 3c500 <ioaddr> <vector> arpa <iface> <qlen> <mtu> [<ip_addr>]
  1740. .LP
  1741. Attach a 3Com 3C501 Ethernet interface.  \fBqlen\fP is the maximum allowable
  1742. transmit queue length.  If the \fBip_addr\fP parameter is not given, the value
  1743. associated with a prior \fBip address\fP command will be used.
  1744. .LP
  1745. The use of this driver is not recommended; use the packet driver interface
  1746. with the loadable 3C501 packet driver instead.
  1747. .NH 2
  1748. attach asy <ioaddr> <vector> ax25 | nrs | ppp | slip <iface> <bufsize> <mtu>
  1749. <speed> [<crv>]
  1750. .LP
  1751. Attach a standard PC "com port" (asynchronous serial port),
  1752. using the National 8250 or 16550A chip.
  1753. Standard values on the IBM PC and clones for \fBioaddr\fP and \fBvector\fP
  1754. are 0x3f8 and 4 for COM1,
  1755. and 0x2f8 and 3 for COM2.
  1756. If the port uses a 16550A chip, it will be detected
  1757. automatically and the FIFOs enabled.
  1758. .NH 3
  1759. ax25
  1760. .LP
  1761. Similar to \fBslip\fP, except that an AX.25 header and a KISS TNC
  1762. control header are added to the front of the datagram before SLIP
  1763. encoding.  Either UI (connectionless) or I (connection-oriented) AX.25
  1764. frames can be used; see the \fBmode\fP command for details. 
  1765. .NH 3
  1766. nrs
  1767. .LP
  1768. Use the NET/ROM asynchronous framing technique for communication with
  1769. a local NET/ROM TNC.
  1770. .NH 3
  1771. ppp
  1772. .LP
  1773. Point-to-Point-Protocol.
  1774. Encapsulates datagrams in an HDLC-like frame.
  1775. This is a new Internet standard for point-to-point communication,
  1776. compatible with CCITT standards.
  1777. .NH 3
  1778. slip
  1779. .LP
  1780. Serial Line Internet Protocol.
  1781. Encapsulates IP datagrams directly in SLIP frames without a link
  1782. header. This is for operation on point-to-point lines and is compatible
  1783. with 4.2BSD UNIX SLIP.
  1784. .NH 3
  1785. <crv>
  1786. .LP
  1787. The optional flags are a string of characters "crv":
  1788. \fBc\fP enables RTS/CTS detection,
  1789. \fBr\fP enables RLSD (Carrier Detect) physical line sensing,
  1790. \fBv\fP enables Van Jacobson TCP/IP Header Compression,
  1791. and is valid only for SLIP.
  1792. .NH 2
  1793. attach drsi <ioaddr> <vector> ax25 <iface> <bufsize> <mtu> <ch_a_speed>
  1794. <ch_b_speed>
  1795. .LP
  1796. N6TTO driver for the Digital Radio Systems PCPA 8530 card.
  1797. Since there are two channels on the board, two interfaces are attached.
  1798. They will be named \fBiface\fP with 'a' and 'b' appended.
  1799. \fBbufsize\fP is the receiver buffer size in bytes;
  1800. it must be larger than the largest frame to be received.
  1801. \fBch_a_speed\fP and \fBch_b_speed\fP are the speeds, in bits/sec,
  1802. for the A and B channels, respectively.
  1803. .NH 2
  1804. attach eagle <ioaddr> <vector> ax25 <iface> <bufsize> <mtu> <speed>
  1805. .LP
  1806. WA3CVG/NG6Q driver for the Eagle Computer card (Zilog 8530).
  1807. .NH 2
  1808. attach hapn <ioaddr> <vector> ax25 <iface> <bufsize> <mtu> csma | full
  1809. .LP
  1810. KE3Z driver for the Hamilton Amateur Packet Network adapter (Intel 8273).
  1811. The \fBcsma | full\fP parameter specifies whether the port should operate in
  1812. carrier sense multiple access (CSMA) mode or in full duplex.
  1813. .NH 2
  1814. attach hs <ioaddr> <vector> ax25 <iface> <bufsize> <mtu> <keyup_delay> <p>
  1815. .LP
  1816. Attach a DRSI PCPA or Eagle Computer interface card
  1817. using a special "high speed" 8530 driver.
  1818. This driver uses busy-wait loops to send and receive
  1819. each byte instead of interrupts, making it usable with high speed modems
  1820. (such as the WA4DSY 56kb/s modem) on slow systems.
  1821. This does have the side effect of "freezing"
  1822. the system whenever the modem transmitter or receiver is active.
  1823. This driver can operate only in CSMA mode, and it is recommended that
  1824. no other interfaces requiring small interrupt latencies be attached to
  1825. the same machine.
  1826. .LP
  1827. The \fBkeyup_delay\fP parameter specifies the transmitter keyup delay in
  1828. byte time intervals. The \fBp\fP value specifies the transmitter persistence
  1829. value in the range 1-255; the corresponding slot time is fixed at one
  1830. hardware clock tick, about 55 ms on the PC.
  1831. .LP
  1832. As with the other 8530 drivers, this driver actually attaches two interfaces,
  1833. one for each 8530 channel.
  1834. .NH 2
  1835. attach packet <intvec> <iface> <txqlen> <mtu>
  1836. .LP
  1837. Driver for use with separate software "packet drivers" meeting the
  1838. FTP Software, Inc, Software Packet Driver specification.
  1839. The driver must have already been installed before the
  1840. \fBattach\fP command is given. Packet drivers in the Ethernet, ARCNET,
  1841. SLIP, SLFP, and KISS/AX25 classes are supported.
  1842. .LP
  1843. \fBintvec\fP is the software interrupt vector used for communication to the
  1844. packet driver, and \fBtxqlen\fP is the maximum number of packets that will
  1845. be allowed on the transmit queue.
  1846. .NH 2
  1847. attach pc100 <ioaddr> <vector> ax25 <iface> <bufsize> <speed>
  1848. .LP
  1849. Driver for the PACCOMM PC-100 (Zilog 8530) card.
  1850. Only AX.25 operation is supported.
  1851. .NH 2
  1852. attach scc <devices> init <addr> <spacing> <Aoff> <Boff> <Dataoff> <intack>
  1853. <vec> [p|r]<clock> [<hdwe>] [<param>]
  1854. .LP
  1855. PE1CHL driver to initialize a generic SCC (8530) interface board
  1856. prior to actually attaching it. The parameters are as follows:
  1857. .NH 3
  1858. <devices>
  1859. .LP
  1860. The number of SCC chips to support.
  1861. .NH 3
  1862. <addr>
  1863. .LP
  1864. The base address of the first SCC chip (hex).
  1865. .NH 3
  1866. <spacing>
  1867. .LP
  1868. The spacing between the SCC chip base addresses.
  1869. .NH 3
  1870. <Aoff>
  1871. .LP
  1872. The offset from a chip's base address to its channel A control register.
  1873. .NH 3
  1874. <Boff>
  1875. .LP
  1876. The offset from a chip's base address to its channel B control register.
  1877. .NH 3
  1878. <Dataoff>
  1879. .LP
  1880. The offset from each channel's control register to its data register.
  1881. .NH 3
  1882. <intack>
  1883. .LP
  1884. The address of the INTACK/Read Vector port. If none,
  1885. specify 0 to read from RR3A/RR2B.
  1886. .NH 3
  1887. <vec>
  1888. .LP
  1889. The CPU interrupt vector for all connected SCCs.
  1890. .NH 3
  1891. <clock>
  1892. .LP
  1893. The clock frequency (PCLK/RTxC) of all SCCs in hertz.
  1894. Prefix with 'p' for PCLK, 'r' for RTxC clock (for baudrate gen).
  1895. .NH 3
  1896. <hdwe>
  1897. .LP
  1898. Optional hardware type. The following values are currently supported:
  1899. 1 - Eagle card, 2 - PACCOMM PC-100, 4 - PRIMUS-PC card (DG9BL), 8 - DRSI
  1900. PCPA card.
  1901. .NH 3
  1902. <param>
  1903. .LP
  1904. Optional extra parameter. At present, this is used only with the PC-100
  1905. and PRIMUS-PC cards to set the modem mode. The value 0x22 is used with
  1906. the PC-100 and 0x2 is used with the PRIMUS-PC card.
  1907. .LP  
  1908. The \fBattach scc ... init\fP command must be given
  1909. before the interfaces are actually attached with the following command.
  1910. .NH 2
  1911. attach scc <chan> slip | kiss | nrs | ax25 <iface> <mtu> <speed> <bufsize> [<call>]
  1912. .LP
  1913. Attach an initialized SCC port to the system. The parameters are as follows:
  1914. .NH 3
  1915. <chan>
  1916. .LP
  1917. The SCC channel number to attach, 0 or 1 for the first chip's A or B port,
  1918. 2 or 3 for the second chip's A or B port, etc.
  1919. .NH 3
  1920. slip | kiss | nrs | ax25
  1921. .LP
  1922. The operating mode of the interface. \fBslip, kiss\fP
  1923. and \fBnrs\fP all operate the
  1924. port hardware in asynchronous mode; \fBslip\fP
  1925. is Internet-standard serial line
  1926. IP mode, \fBkiss\fP generates SLIP frames containing KISS TNC commands and
  1927. AX.25 packets and \fBnrs\fP uses NET/ROM local serial link framing conventions
  1928. to carry NET/ROM packets. Selecting \fBax25\fP mode puts the interface into
  1929. synchronous HDLC mode that is suitable for direct connection to a half duplex
  1930. radio modem.
  1931. .NH 3
  1932. <speed>
  1933. .LP
  1934. The interface speed in bits per second (eg. 1200).
  1935. Prefix with 'd' when an external divider
  1936. is available to generate the TX clock. When the clock source is PCLK,
  1937. this can be a /32 divider between TRxC and RTxC. When the clock is at RTxC,
  1938. the TX rate must be supplied at TRxC. This is needed only for full duplex
  1939. synchronous operation. When this arg is given as 'ext', the transmit and
  1940. receive clocks are external, and the internal baud rate generator (BRG)
  1941. and digital phase locked loop (DPLL) are not used.
  1942. .NH 2
  1943. Attach Examples
  1944. .LP
  1945. Here are some examples of the attach command:
  1946. .LP
  1947. .DS I 0
  1948. .ft CW
  1949. # Attach a 3Com Ethernet controller using the standard 3Com address and
  1950. # vector (i.e., as it comes out of the box) to use ARPA-standard encapsulation.
  1951. # The receive queue is limited to 5 packets, and outgoing packets larger
  1952. # than 1500 bytes will be fragmented
  1953. attach 3c500 0x300 3 arpa ec0 5 1500
  1954.  
  1955. # Attach the PC asynch card normally known as "com1" (the first controller)
  1956. # to operate in point-to-point slip mode at 9600 baud, calling it "sl0".
  1957. # A 1024 byte receiver ring buffer is allocated. Outgoing packets larger
  1958. # than 256 bytes are fragmented.
  1959. attach asy 0x3f8 4 slip sl0 1024 256 9600
  1960.  
  1961. # Attach the secondary PC asynch card ("com2") to operate in AX.25 mode
  1962. # with an MTU of 576 bytes at 9600 baud with a KISS TNC, calling it "ax0".
  1963. # By default, IP datagrams are sent in UI frames
  1964. attach asy 0x2f8 3 ax25 ax0 1024 576 9600
  1965.  
  1966. # Attach the packet driver loaded at interrupt 0x7e
  1967. # The packet driver is for an Ethernet interface
  1968. attach packet 0x7e ethernet 8 1500
  1969. .ft P
  1970. .DE
  1971. .LP
  1972. .bp
  1973. .NH 1
  1974. FTP Subcommands
  1975. .LP
  1976. During converse mode with an FTP server, everything typed on the console is
  1977. first examined to see if it is a locally-known command. If not, the line is
  1978. passed intact to the remote server on the control channel. If it is one of
  1979. the following commands, however, it is executed locally. (Note that this
  1980. generally involves other commands being sent to the remote server on the
  1981. control channel.)
  1982. .NH 2
  1983. dir [<file> | <directory> [<local file>]]
  1984. .LP
  1985. Without arguments,
  1986. \fBdir\fP requests that a full directory listing of the remote
  1987. server's current directory be sent to the terminal.  If one argument is
  1988. given, this is passed along in the LIST command; this can be a specific
  1989. file or subdirectory that is meaningful to the remote file system. If two
  1990. arguments are given, the second is taken as the local file into which the
  1991. directory listing should be put (instead of being sent to the console).
  1992. The PORT command is used before the LIST command is sent.
  1993. .NH 2
  1994. get <remote file> [<local file>]
  1995. .LP
  1996. Asks the remote server to send the file specified in the first argument.
  1997. The second argument, if given, will be the name of the file on the local
  1998. machine; otherwise it will have the same name as on the remote machine.
  1999. The PORT and RETR commands are sent on the control channel.
  2000. .NH 2
  2001. hash
  2002. .LP
  2003. A synonym for the \fBverbose 3\fP command.
  2004. .NH 2
  2005. ls [<file> | <directory> [<local file>]]
  2006. .LP
  2007. \fBls\fP is identical to the \fBdir\fP command except that the "NLST"
  2008. command is
  2009. sent to the server instead of the "LIST" command. This results in an
  2010. abbreviated directory listing, i.e., one showing only the file names
  2011. themselves without any other information.
  2012. .NH 2
  2013. mget <file> [<file> ...]
  2014. .LP
  2015. Fetch a collection of files from the server. File names may include
  2016. wild card characters; they will be interpreted and expanded into a
  2017. list of files by the remote
  2018. system using the NLST command. The files will have the same name on
  2019. the local system that they had on the server.
  2020. .NH 2
  2021. mkdir <remote directory>
  2022. .LP
  2023. Creates a directory on the remote machine.
  2024. .NH 2
  2025. mput <file> [<file> ...]
  2026. .LP
  2027. Send a collection of files to the server. File names may include
  2028. wild card characters; they will be expanded locally into a list
  2029. of files to be sent. The files will have the same name on the
  2030. server as on the local system.
  2031. .NH 2
  2032. put <local file> [<remote file>]
  2033. .LP
  2034. Asks the remote server to accept data, creating the file named in the
  2035. first argument. The second argument, if given, will be the name of the file
  2036. on the remote machine; otherwise it will have the same name as on the local
  2037. machine.  The PORT and STOR commands are sent on the control channel.
  2038. .NH 2
  2039. rmdir <remote directory>
  2040. .LP
  2041. Deletes a directory on the remote machine.
  2042. .NH 2
  2043. type [a | i | l <bytesize>]
  2044. .LP
  2045. Tells both the local client and remote server the type of file that is
  2046. to be transferred.  The default is 'a', which means ASCII (i.e., a text
  2047. file).  Type 'i' means \fIimage\fP, i.e., binary.  In ASCII mode, files are
  2048. sent as varying length lines of text in ASCII separated by cr/lf
  2049. sequences; in IMAGE mode, files are sent exactly as they appear in the
  2050. file system.  ASCII mode should be used whenever transferring text
  2051. between dissimilar systems (eg. UNIX and MS-DOS) because of their
  2052. different end-of-line and/or end-of-file conventions.  When exchanging
  2053. text files between machines of the same type, either mode will work but
  2054. IMAGE mode is usually faster.  Naturally, when exchanging raw
  2055. binary files (executables, compressed archives, etc) IMAGE mode must be
  2056. used.  Type 'l' (logical byte size) is used when exchanging binary files
  2057. with remote servers having oddball word sizes (eg. DECSYSTEM-10s and 20s).
  2058. Locally it works exactly like IMAGE, except that it notifies the
  2059. remote system how large the byte size is. \fBbytesize\fP is typically 8.
  2060. The type command sets the local transfer mode and generates the TYPE
  2061. command on the control channel. 
  2062. .NH 2
  2063. verbose [0 | 1 | 2 | 3]
  2064. .LP
  2065. Set or display the level of message output in file transfers.
  2066. \fBVerbose 0\fP gives the least output, and \fBverbose 3\fP the most,
  2067. as follows:
  2068. .DS I 0
  2069. 0 - Display error messages only.
  2070. 1 - Display error messages plus a one-line summary after each transfer
  2071.     giving the name of the file, its size, and the transfer time and rate.
  2072. 2 - Display error and summary messages plus the progress messages generated
  2073.     by the remote FTP server. (This setting is the default.)
  2074. 3 - Display all messages. In addition, a "hash mark" (#) is displayed for
  2075.     every 1,000 bytes sent or received.
  2076. .DE
  2077. If a command is sent to the
  2078. remote server because it is not recognized locally, the response
  2079. is always displayed, regardless of the setting of \fBverbose\fP.
  2080. This is necessary for commands like \fBpwd\fP (display working directory),
  2081. which would
  2082. otherwise produce no message at all if \fBverbose\fP were set to 0 or 1.
  2083. .bp
  2084. .NH 1
  2085. Dialer Subcommands
  2086. .LP
  2087. Each dialer command may (should) have a different dialer file.
  2088. The file resides in the configuration directory,
  2089. as specified in the \fBInstallation\fP section (see chapter 1).
  2090. A typical dialer file might be:
  2091. .DS
  2092. # Set the speed, and toggle DTR to ensure modem is in command mode.
  2093. control down
  2094. wait 3000
  2095. speed 2400
  2096. control up
  2097. wait 3000
  2098. # Dial, and wait for connection
  2099. send "atdt555-1212\\r"
  2100. wait 45000 "CONNECT " speed
  2101. wait 2000
  2102. # PAD specific initialization
  2103. send "\\r"
  2104. wait 15000 "Terminal ="
  2105. send "ppp\\r"
  2106. wait 10000 "\\r\\n"
  2107. .DE
  2108. .NH 3
  2109. control down | up
  2110. .LP
  2111. Control \fBasy\fP interface.
  2112. The \fBdown\fP option drops DTR and RTS.
  2113. The \fBup\fP option asserts DTR and RTS.
  2114. .NH 3
  2115. send "string"
  2116. .LP
  2117. This dialer command will write the specified string to the interface.
  2118. The string quote marks are required,
  2119. and the string may not contain embedded control characters.
  2120. However, the standard C string escape sequences are recognized
  2121. (\\0 should not be used).
  2122. .NH 3
  2123. speed [ 9600 | 4800 | 2400 | 1200 | 300 ]
  2124. .LP
  2125. This dialer command will set the speed of the interface to one of the
  2126. available speeds.
  2127. If the speed is missing,
  2128. the speed will be displayed in the dialer session window.
  2129. .NH 3
  2130. wait <milliseconds> [ "test string" ] [ speed ]
  2131. .LP
  2132. If only the time is specified,
  2133. the dialer pauses for the desired number of milliseconds.
  2134. .LP
  2135. Otherwise, the dialer reads until the test string is detected on the interface.
  2136. If the string is not detected within the desired time,
  2137. the autodialer will reset.
  2138. The string quote marks are required,
  2139. and the string may not contain embedded control characters.
  2140. However, the standard C string escape sequences are recognized
  2141. (\\0 should not be used).
  2142. .LP
  2143. Finally, if the \fIspeed\fP parameter is specified,
  2144. the dialer will continue to read characters until a non-digit is detected.
  2145. The string read is converted to an integer,
  2146. and used to set the interface speed.
  2147. If the trailing non-digit is not detected within the desired time,
  2148. or the integer value is not a valid speed,
  2149. the autodialer will reset.
  2150. .bp
  2151. .NH 1
  2152. The /ftpusers File
  2153. .LP
  2154. Since MS-DOS is a single-user operating system (some might say it is
  2155. a glorified bootstrap loader), it provides
  2156. no access control; all files can be read, written or deleted by the
  2157. local user.  It is usually undesirable to give such open access to a
  2158. system to remote network users.  \fBNet.exe\fP therefore provides its own
  2159. access control mechanisms.
  2160. .LP
  2161. The file \fB/ftpusers\fP controls remote FTP and mailbox access.
  2162. The FTP default
  2163. is \fIno\fP access; if this file does not exist, the FTP server will be
  2164. unusable.  A remote user must first "log in" to the system with the USER
  2165. and PASS commands, giving a valid name and password listed in \fB/ftpusers\fP,
  2166. before he or she can transfer files. 
  2167. .LP
  2168. Each entry in \fB/ftpusers\fP consists of a single line of the form
  2169. .DS I 0
  2170. .ft CW
  2171. username password /path permissions
  2172. .ft P
  2173. .DE
  2174. .LP
  2175. There must be exactly four fields, and there must be exactly one space
  2176. between each field.  Comments may be added after the last field. 
  2177. Comment lines begin with '#' in column one. 
  2178. .LP
  2179. \fBusername\fP is the user's login name.
  2180. .LP
  2181. \fBpassword\fP is the required password.  Note that this is in
  2182. plain text; therefore it is not a good idea to give general read
  2183. permission to the root directory.  A password of '*' (a single asterisk)
  2184. means that any password is acceptable. 
  2185. .LP
  2186. \fB/path\fP is the allowable prefix on accessible files.  Before any
  2187. file or directory operation, the current directory and the user-
  2188. specified file name are joined to form an absolute path name in
  2189. "canonical" form (i.e., a full path name starting at the root, with "./"
  2190. and "../" references, as well as redundant /'s, recognized and removed). 
  2191. The result MUST begin with the allowable path prefix; if not, the
  2192. operation is denied.  This field must always begin with a
  2193. "/", i.e., at the root directory. 
  2194. .LP
  2195. \fBpermissions\fP is a decimal number granting permission for read,
  2196. create and write operations.  If the low order bit (0x1) is set, the
  2197. user is allowed to read a file subject to the path name prefix
  2198. restriction.  If the next bit (0x2) is set, the user is allowed to
  2199. create a new file if it does not overwrite an existing file.  If the
  2200. third bit (0x4) is set, the user is allowed to write a file even if it
  2201. overwrites an existing file, and in addition he may delete files.  Again,
  2202. all operations are allowed subject to the path name prefix restrictions. 
  2203. Permissions may be combined by adding bits, for example, 0x3 (= 0x2 + 0x1)
  2204. means that the user is given read and create permission, but not
  2205. overwrite/delete permission.
  2206. .LP
  2207. For example, suppose \fB/ftpusers\fP on machine
  2208. pc.ka9q.ampr.org contains the line
  2209. .DS I 0
  2210. .ft CW
  2211. friendly test /testdir 7
  2212. .ft P
  2213. .DE
  2214. .LP
  2215. A session using this account would look like this:
  2216. .DS I 0
  2217. .ft CW
  2218. net> ftp pc.ka9q.ampr.org
  2219. Resolving pc.ka9q.ampr.org... Trying 128.96.160.1...
  2220. FTP session 1 connected to pc.ka9q.ampr.org
  2221. 220 pc.ka9q.ampr.org FTP version 900418 ready at Mon May 7 16:27:18 1990
  2222. Enter user name: friendly
  2223. 331 Enter PASS command
  2224. Password: test [not echoed]
  2225. 230 Logged in
  2226. ftp>
  2227. .ft P
  2228. .DE
  2229. .LP
  2230. The user now has read, write, overwrite and delete privileges for any file
  2231. under /testdir; he may not access any other files.
  2232. .LP
  2233. Here are some more sample entries in \fB/ftpusers\fP:
  2234. .DS I 0
  2235. .ft CW
  2236. karn foobar / 7         # User "karn" with password "foobar" may read,
  2237.                         # write, overwrite and delete any file on the
  2238.                         # system.
  2239.  
  2240. guest bletch /g/bogus 3 # User "guest" with password "bletch" may read
  2241.                         # any file under /g/bogus and its subdirectories,
  2242.                         # and may create a new file as long as it does
  2243.                         # not overwrite an existing file. He may NOT
  2244.                         # delete any files.
  2245.  
  2246. anonymous * /public 1   # User "anonymous" (any password) may read files
  2247.                         # under /public and its subdirectories; he may
  2248.                         # not create, overwrite or delete any files.
  2249. .ft
  2250. .DE
  2251. .LP
  2252. This last entry is the standard convention for keeping a repository of
  2253. public files; in particular, the username "anonymous" is an established
  2254. ARPA convention. 
  2255. .bp
  2256. .NH 1
  2257. The \fBdomain.txt\fP File
  2258. .LP
  2259. \fBNet.exe\fP translates domain names (eg. "pc.ka9q.ampr.org") to IP addresses
  2260. (eg. 128.96.160.3) through the use of an Internet Domain Name resolver and
  2261. a local "cache" file, \fBdomain.txt\fP.
  2262. Whenever the user specifies a domain name,
  2263. the local cache is searched for the desired entry.
  2264. If it is present, it is used;
  2265. if not, and if domain name server(s) have been configured,
  2266. a query is sent over the network to the current server.
  2267. If the server responds,
  2268. the answer is added to the \fBdomain.txt\fP file for future use.
  2269. If the server does not respond, any additional servers on the list are
  2270. tried in a round-robin fashion until one responds,
  2271. or the retry limit is reached (see the \fBdomain retry\fP command).
  2272. If \fBdomain.txt\fP does not contain the
  2273. desired entry and there are no configured domain name servers,
  2274. then the request immediately fails.
  2275. .LP
  2276. If a domain name server is available, and if all references to host-ids in
  2277. your /\fBautoexec.net\fP file are in IP address format, then it is
  2278. possible to start with a completely empty \fBdomain.txt\fP file
  2279. and have \fBnet.exe\fP build it for you.
  2280. However, you may wish to add your own entries to \fBdomain.txt\fP,
  2281. either because you prefer to use symbolic domain names in your
  2282. /\fBautoexec.net\fP file
  2283. or you don't have access to a domain server and you need to create entries
  2284. for all of the hosts you may wish to access.
  2285. .LP
  2286. Each entry takes one line,
  2287. and the fields are separated by any combination of tabs or spaces.
  2288. For example:
  2289. .DS I 0
  2290. pc.ka9q.ampr.org.    IN    A    128.96.160.3
  2291. .DE
  2292. \fBIN\fP is the \fIclass\fP of the record.
  2293. It means \fIInternet\fP, and it will be found in all entries.
  2294. \fBA\fP is the \fItype\fP of the record, and it means that this is
  2295. an \fIaddress\fP record.
  2296. Domain name \fBpc.ka9q.ampr.org\fP therefore has Internet
  2297. address 128.96.160.3.
  2298. .LP
  2299. Another possible entry is the \fBCNAME\fP (Canonical Name) record.
  2300. For example:
  2301. .DS I 0
  2302. ka9q.ampr.org.        IN    CNAME    pc.ka9q.ampr.org.
  2303. .DE
  2304. This says that domain name "ka9q.ampr.org" is actually an alias for the
  2305. system with (primary, or \fIcanonical\fP) domain name "pc.ka9q.ampr.org."
  2306. When a domain name having a \fBCNAME\fP
  2307. record is given to \fBnet.exe\fP, the system
  2308. automatically follows the reference to the canonical name and returns the
  2309. IP address associated with that entry.
  2310. .LP
  2311. Entries added automatically by \fBnet.exe\fP will have an additional field between
  2312. the domain name and the class (\fBIN\fP) field.  For example:
  2313. .DS I 0
  2314. pc.ka9q.ampr.org.    3600    IN    A    128.96.160.3
  2315. .DE
  2316. This is the \fItime-to-live\fP value, in seconds, associated with the record
  2317. received from the server. Clients (such as \fBnet.exe\fP) caching these records are
  2318. supposed to delete them after the time-to-live interval has expired,
  2319. allowing for the possibility that the information in the record may become
  2320. out of date.
  2321. .LP
  2322. This implementation of \fBnet.exe\fP will decrement the TTL to zero, but will not
  2323. delete the record unless the "clean" flag is on
  2324. (see the \fBdomain cache clean\fP command).
  2325. When a remote server is not available, the old entry will be used.
  2326. .LP
  2327. When the \fITTL\fP value is missing (as in the examples above),
  2328. the record will never expire, and must be managed by hand.
  2329. Since \fBdomain.txt\fP is a plain text file,
  2330. it may be easily edited by the user to add, change or delete records.
  2331. .LP
  2332. Additional types of records, include NS (name server) and SOA (start of
  2333. authority) may appear in \fBdomain.txt\fP from remote server responses. These
  2334. are not currently used by \fBnet.exe\fP but are retained for future development
  2335. (such as the incorporation of a domain name server into \fBnet.exe\fP itself).
  2336. .bp
  2337. .NH 1
  2338. Setting Bufsize, Paclen, Maxframe, MTU, MSS and Window
  2339. .LP
  2340. Many \fBnet.exe\fP users are confused by these parameters and do not know how to
  2341. set them properly. This chapter will first review these parameters and
  2342. then discuss how to choose values for them. Special emphasis is given to
  2343. avoiding interoperability problems that may appear when communicating
  2344. with non-\fBnet.exe\fP implementations of AX.25.
  2345. .NH 2
  2346. Hardware Parameters
  2347. .LP
  2348. .NH 3
  2349. Bufsize
  2350. .LP
  2351. This parameter is required by most of \fBnet.exe\fP's built-in HDLC drivers
  2352. (eg. those for the DRSI PCPA and the Paccomm PC-100). It specifies the size
  2353. of the buffer to be allocated for each receiver port. HDLC frames
  2354. larger than this value cannot be received.
  2355. .LP
  2356. There is no default \fBbufsize\fP; it must be specified in the \fBattach\fP
  2357. command for the interface.
  2358. .NH 2
  2359. AX25 Parameters
  2360. .NH 3
  2361. Paclen
  2362. .LP
  2363. Paclen limits the size of the data field in an AX.25 I-frame. This
  2364. value does \fInot\fP include the AX.25 protocol header (source,
  2365. destination and digipeater addresses).
  2366. .LP
  2367. Since unconnected-mode (datagram) AX.25 uses UI frames, this parameter
  2368. has no effect in unconnected mode.
  2369. .LP
  2370. The default value of \fBpaclen\fP is 256 bytes.
  2371. .NH 3
  2372. Maxframe
  2373. .LP
  2374. This parameter controls the number of I-frames that \fBnet.exe\fP may send
  2375. on an AX.25 connection before it must stop and wait for an acknowledgement.
  2376. Since the AX.25/LAPB sequence number field is 3 bits wide, this number
  2377. cannot be larger than 7.
  2378. .LP
  2379. Since unconnected-mode (datagram) AX.25 uses UI frames that do not have
  2380. sequence numbers, this parameter does \fInot\fP apply to unconnected
  2381. mode.
  2382. .LP
  2383. The default value of \fBmaxframe\fP in \fBnet.exe\fP is 1 frame.
  2384. .NH 2
  2385. IP and TCP Parameters
  2386. .NH 3
  2387. MTU
  2388. .LP
  2389. The MTU (Maximum Transmission Unit) is an interface parameter that
  2390. limits the size of the largest IP
  2391. datagram that it may handle.  IP datagrams routed to
  2392. an interface that are larger than its MTU are each split into two or more
  2393. \fIfragments\fP.
  2394. Each fragment has its own IP header and is handled by the network
  2395. as if it were a distinct IP datagram, but when it arrives at
  2396. the destination it is held by the IP layer until all of the other fragments
  2397. belonging to the original datagram have arrived. Then they are reassembled
  2398. back into the complete, original IP datagram. 
  2399. The minimum acceptable interface MTU is 28
  2400. bytes: 20 bytes for the IP (fragment) header, plus 8 bytes of data.
  2401. .LP
  2402. There is no default MTU in \fBnet.exe\fP; it must be explicitly specified for
  2403. each interface as part of the \fBattach\fP command.
  2404. .NH 3
  2405. MSS
  2406. .LP
  2407. MSS (Maximum Segment Size) is a TCP-level parameter that limits the
  2408. amount of data that the \fIremote\fP TCP will send in a single TCP
  2409. packet. MSS values are exchanged in the SYN (connection request)
  2410. packets that open a TCP connection. In the \fBnet.exe\fP implementation of TCP,
  2411. the MSS actually used by TCP is further reduced in order to avoid
  2412. fragmentation at the local IP interface. That is, the local TCP asks IP
  2413. for the MTU of the interface that will be used to reach the
  2414. destination. It then subtracts 40 from the MTU value to allow for the
  2415. overhead of the TCP and IP headers. If the result is less than the MSS
  2416. received from the remote TCP, it is used instead.
  2417. .LP
  2418. The default value of \fBMSS\fP is 512 bytes.
  2419. .NH 3
  2420. Window
  2421. .LP
  2422. This is a TCP-level parameter that controls how much data the local TCP
  2423. will allow the remote TCP to send before it must stop and wait for an
  2424. acknowledgement. The actual window value used by TCP when deciding how
  2425. much more data to send is referred to as the \fIeffective window\fP.
  2426. This is the smaller of two values: the window advertised by the remote
  2427. TCP minus the unacknowledged data in flight, and the \fIcongestion
  2428. window\fP, an automatically computed time-varying estimate of how much
  2429. data the network can handle.
  2430. .LP
  2431. The default value of \fBWindow\fP is 2048 bytes.
  2432. .NH 2
  2433. Discussion
  2434. .LP
  2435. .NH 3
  2436. IP Fragmentation vs AX.25 Segmentation
  2437. .LP
  2438. IP-level fragmentation often makes it possible to interconnect two
  2439. dissimilar networks, but it is best avoided whenever possible.
  2440. One reason is that when a single IP fragment is lost, all other fragments
  2441. belonging to the same datagram are effectively also lost and
  2442. the entire datagram must be retransmitted by the source.
  2443. Even without loss, fragments require the allocation of temporary buffer
  2444. memory at the destination, and it is never easy
  2445. to decide how long to wait for missing fragments before
  2446. giving up and discarding those that have already arrived.
  2447. A reassembly timer controls this process.
  2448. In \fBnet.exe\fP it is (re)initialized with the \fBip rtimer\fP parameter
  2449. (default 30 seconds) whenever progress is made in reassembling a datagram
  2450. (i.e., a new fragment is received).
  2451. It is not necessary that all of the fragments belonging to a datagram
  2452. arrive within a single timeout interval, only that the interval between
  2453. fragments be less than the timeout.
  2454. .LP
  2455. Most subnetworks that carry IP have MTUs of 576 bytes or more, so
  2456. interconnecting them with subnetworks having smaller values can result in
  2457. considerable fragmentation. For this reason, IP implementors working with
  2458. links or subnets having unusually small packet size limits are encouraged
  2459. to use
  2460. \fItransparent fragmentation\fP,
  2461. that is, to devise schemes to break up large IP
  2462. datagrams into a sequence of link or subnet frames that are immediately
  2463. reassembled on the other end of the link or subnet into the original, whole IP
  2464. datagram without the use of IP-level fragmentation. Such a
  2465. scheme is provided in AX.25 Version 2.1.  It can break
  2466. a large IP or NET/ROM datagram into a series of \fBpaclen\fP-sized
  2467. AX.25 segments (not to be confused with TCP segments),
  2468. one per AX.25 I-frame, for transmission and reassemble them into
  2469. a single datagram at the other end of the link before handing it up to the
  2470. IP or NET/ROM module.  Unfortunately, the segmentation procedure is a new
  2471. feature in AX.25 and is not yet widely implemented;
  2472. in fact, \fBnet.exe\fP is so far
  2473. the only known implementation. This creates some interoperability problems
  2474. between \fBnet.exe\fP and non-\fBnet.exe\fP nodes, in particular, standard
  2475. NET/ROM nodes being used to carry IP datagrams. This problem is discussed
  2476. further in the section on setting the MTU.
  2477. .NH 3
  2478. Setting paclen and bufsize
  2479. .LP
  2480. The more data you put into an AX.25 I frame, the smaller the AX.25
  2481. headers are in relation to the total frame size. In other words, by
  2482. increasing \fBpaclen\fP, you lower the AX.25 protocol overhead. Also, large
  2483. data packets reduce the overhead of keying up a transmitter, and this
  2484. can be an important factor with higher speed modems. On the other hand,
  2485. large frames make bigger targets for noise and interference. Each link
  2486. has an optimum value of \fBpaclen\fP that is best discovered by experiment.
  2487. .LP
  2488. Another thing to remember when setting \fBpaclen\fP is that the AX.25 version
  2489. 2.0 specification limits it to 256 bytes. Although \fBnet.exe\fP can handle
  2490. much larger values, some other AX.25 implementations (including
  2491. digipeaters) cannot and this
  2492. may cause interoperability problems. Even \fBnet.exe\fP may have trouble with
  2493. certain KISS TNCs because of fixed-size buffers. The original KISS TNC
  2494. code for the TNC-2 by K3MC can handle frames limited in size only by
  2495. the RAM in the TNC, but some other KISS TNCs cannot.
  2496. .LP
  2497. \fBNet.exe\fP's built-in HDLC drivers (SCC, PC-100, DRSI, etc) allocate receive
  2498. buffers according to the maximum expected frame size, so it is
  2499. important that these devices be configured with the correct
  2500. \fBbufsize\fP. To do this, you must know the size of the largest
  2501. possible frame that can be received. The \fBpaclen\fP parameter
  2502. controls only the size of the data field in an I-frame and not the
  2503. total size of the frame as it appears on the air. The AX.25 spec allows
  2504. up to 8 digipeaters, so the largest possible frame is (\fBpaclen\fP + 72)
  2505. bytes. So you should make \fBbufsize\fP at least this large.
  2506. .LP
  2507. Another important consideration is that the more recent versions of NOS
  2508. improve interrupt response by maintaining a special pool of buffers for use
  2509. by the receive routines.  These buffers are currently fixed in size to 2048
  2510. bytes and this can be changed only by editing config.h and recompiling NOS.
  2511. This limits \fBbufsize\fP; in fact, attempting to set a larger value may
  2512. cause the driver not to work at all. This situation can be detected by
  2513. running the \fBmemory status\fP command and looking for a non-zero count
  2514. of \fBIbuffail\fP events, although these events can also occur
  2515. occasionally during normal operation.
  2516. .LP
  2517. One of the drawbacks of AX.25 that there is no way for one station to tell
  2518. another how large a packet it is willing to accept.  This requires the
  2519. stations sharing a channel to agree beforehand on a maximum packet size.
  2520. TCP is different, as we shall see.
  2521. .NH 3
  2522. Setting Maxframe
  2523. .LP
  2524. For best performance on a half-duplex radio channel, \fBmaxframe\fP should
  2525. always be set to 1. The reasons are explained in the paper \fILink Level
  2526. Protocols Revisited\fP by Brian Lloyd and Phil Karn, which appeared in the
  2527. proceedings of the ARRL 5th Computer Networking Conference in 1986.
  2528. .NH 3
  2529. Setting MTU
  2530. .LP
  2531. TCP/IP header overhead considerations similar to those of the AX.25 layer
  2532. when setting \fBpaclen\fP apply when choosing an MTU.  However, certain
  2533. subnetwork types supported by \fBnet.exe\fP have well-established MTUs, and
  2534. these should
  2535. always be used unless you know what you're doing: 1500 bytes for Ethernet,
  2536. and 508 bytes for ARCNET.
  2537. The MTU for PPP is automatically negotiated, and defaults to 1500.
  2538. Other subnet types, including SLIP and AX.25, are
  2539. not as well standardized.
  2540. .LP
  2541. SLIP has no official MTU, but the most common
  2542. implementation (for BSD UNIX) uses an MTU of 1006 bytes.  Although
  2543. \fBnet.exe\fP has no hard wired limit on the size of a received SLIP frame,
  2544. this is not true for other systems.
  2545. Interoperability problems may therefore result if larger MTUs are used in
  2546. \fBnet.exe\fP.
  2547. .LP
  2548. Choosing an MTU for an AX.25 interface is more complex. When the interface
  2549. operates in datagram (UI-frame) mode, the \fBpaclen\fP parameter does not
  2550. apply. The MTU effectively becomes the \fBpaclen\fP of the link.  However,
  2551. as mentioned earlier, large packets sent on AX.25 \fIconnections\fP are
  2552. automatically segmented into I-frames no larger than \fBpaclen\fP bytes.
  2553. Unfortunately, as also mentioned earlier, \fBnet.exe\fP is so far the only known
  2554. implementation of the new AX.25 segmentation procedure. This is fine as long
  2555. as all of the NET/ROM nodes along a path are running \fBnet.exe\fP, but since the main
  2556. reason \fBnet.exe\fP supports NET/ROM is to allow use of existing NET/ROM networks,
  2557. this is unlikely.
  2558. .LP
  2559. So it is usually important to avoid AX.25 segmentation when running IP over
  2560. NET/ROM.  The way to do this is to make sure that packets larger
  2561. than \fBpaclen\fP are never handed to AX.25.  A NET/ROM transport header is
  2562. 5 bytes long and a NET/ROM network header takes 15 bytes, so 20 bytes must
  2563. be added to the size of an IP datagram when figuring the size of the AX.25
  2564. I-frame data field. If \fBpaclen\fP is 256, this leaves 236 bytes for the IP
  2565. datagram. This is the default MTU of the \fBnetrom\fP pseudo-interface, so
  2566. as long as \fBpaclen\fP is at least 256 bytes, AX.25 segmentation can't
  2567. happen. But if smaller values of \fBpaclen\fP are used, the \fBnetrom\fP MTU
  2568. must also be reduced with the \fBifconfig\fP command.
  2569. .LP
  2570. On the other hand, if you're running IP directly on top of AX.25, chances
  2571. are all of the nodes are running \fBnet.exe\fP and support AX.25 segmentation.
  2572. In this case there is no reason not to use a larger MTU and let
  2573. AX.25 segmentation do its thing. If you choose
  2574. an MTU on the order of 1000-1500 bytes, you can largely avoid IP-level
  2575. fragmentation and reduce TCP/IP-level header overhead on file transfers
  2576. to a very low level.
  2577. And you are still free to pick whatever \fBpaclen\fP value is
  2578. appropriate for the link.
  2579. .NH 3
  2580. Setting MSS
  2581. .LP
  2582. The setting of this TCP-level parameter is somewhat less critical than the
  2583. IP and AX.25 level parameters already discussed, mainly because it is
  2584. automatically lowered according to the MTU of the local interface when a
  2585. connection is created. Although this is, strictly speaking, a protocol
  2586. layering violation (TCP is not supposed to have any knowledge of the
  2587. workings of lower layers) this technique does work well in practice.
  2588. However, it can be fooled; for example, if a routing change occurs after the
  2589. connection has been opened and the new local interface has a smaller MTU
  2590. than the previous one, IP fragmentation may occur in the local system.
  2591. .LP
  2592. The only drawback to setting a large MSS is that it might cause avoidable
  2593. fragmentation at some other point within the network path if it includes a
  2594. "bottleneck" subnet with an MTU smaller than that of the local interface.
  2595. (Unfortunately, there is presently no way to know when this is the case.
  2596. There is ongoing work within the Internet Engineering Task Force on a "MTU
  2597. Discovery" procedure to determine the largest datagram that may be sent over
  2598. a given path without fragmentation, but it is not yet complete.)
  2599. Also, since the MSS you specify is sent to the remote system, and not all
  2600. other TCPs do the MSS-lowering procedure yet, this might cause the remote
  2601. system to generate IP fragments unnecessarily.
  2602. .LP
  2603. On the other hand, a too-small MSS can result in a considerable performance
  2604. loss, especially when operating over fast LANs and networks that can handle
  2605. larger packets. So the best value for MSS is probably 40 less than the
  2606. largest MTU on your system, with the 40-byte margin allowing for the TCP and
  2607. IP headers. For example, if you have a SLIP interface with a 1006 byte MTU
  2608. and an Ethernet interface with a 1500 byte MTU, set MSS to 1460 bytes. This
  2609. allows you to receive maximum-sized Ethernet packets, assuming the path to
  2610. your system does not have any bottleneck subnets with smaller MTUs.
  2611. .NH 3
  2612. Setting Window
  2613. .LP
  2614. A sliding window protocol like TCP cannot transfer more than one window's
  2615. worth of data per round trip time interval. So this TCP-level parameter
  2616. controls the ability of the remote TCP to keep a long "pipe" full. That is,
  2617. when operating over a path with many hops, offering a large TCP window will
  2618. help keep all those hops busy when you're receiving data. On the other hand,
  2619. offering too large a window can congest the network if it cannot buffer all
  2620. that data. Fortunately, new algorithms for dynamic controlling the
  2621. effective TCP flow control window have been developed over the past few
  2622. years and are now widely deployed.
  2623. \fBNet.exe\fP includes them, and you can watch them
  2624. in action with the \fBtcp status <tcb>\fP or \fBsocket <sockno>\fP commands.
  2625. Look at the \fBcwind\fP (congestion window) value.
  2626. .LP
  2627. In most cases it is safe to set the TCP window to a small integer
  2628. multiple of the MSS (eg. 4 times), or larger if necessary to fully utilize a
  2629. high bandwidth*delay product path. One thing to keep in mind, however, is
  2630. that advertising a certain TCP window value declares that the system has
  2631. that much buffer space available for incoming data.
  2632. \fBNet.exe\fP does not actually preallocate this space;
  2633. it keeps it in a common pool and may well "overbook" it,
  2634. exploiting the fact that many TCP connections are idle for long periods
  2635. and gambling that most applications will read incoming data from an active
  2636. connection as soon as it arrives, thereby quickly freeing the buffer memory.
  2637. However, it is possible to run \fBnet.exe\fP out of memory if excessive TCP window
  2638. sizes are advertised and either the applications go to sleep indefinitely
  2639. (eg. suspended Telnet sessions) or a lot of out-of-sequence data arrives.
  2640. It is wise to keep an eye on the amount of available memory and to decrease
  2641. the TCP window size (or limit the number of simultaneous connections) if it
  2642. gets too low.
  2643. .LP
  2644. Depending on the channel access method and link level protocol, the use
  2645. of a window setting that exceeds the MSS may cause an increase in channel
  2646. collisions. In particular, collisions between data packets and returning
  2647. acknowledgements during a bulk file transfer
  2648. may become common. Although this is, strictly speaking,
  2649. not TCP's fault, it is possible to work around the problem at the TCP level
  2650. by decreasing the window so that the protocol operates in stop-and-wait mode.
  2651. This is done by making the window value equal to the MSS.
  2652. .NH 2
  2653. Summary
  2654. .LP
  2655. In most cases, the default values provided by \fBnet.exe\fP for each of these
  2656. parameters
  2657. will work correctly and give reasonable performance. Only in special
  2658. circumstances such as operation over a very poor link or experimentation
  2659. with high speed modems should it be necessary to change them.
  2660.